Skip to content
YAML / JSON / TOML

YAML, JSON, TOML converter

Bidirectional conversion between YAML, JSON and TOML. Auto-detect source format, strict validation that pinpoints the location of a syntax error, instant swap between input and output for round-trip tests. Typical for multi-stack engineers: jump from a Kubernetes YAML manifest to wire JSON, from a pyproject.toml to the JSON of an API payload, from a .github/workflows/*.yml to its equivalent struct representation.

How to use the converter

  1. 1

    Paste the source

    YAML, JSON or TOML. Auto-detect recognizes the format from the syntax (JSON starts with { or [, TOML has [section] or key = value, YAML is the fallback).

  2. 2

    Pick the target

    JSON, YAML or TOML. Conversion goes through an intermediate JavaScript object: lossless roundtrip for YAML/JSON, lossy admitted for TOML on edge cases (complex datetime offsets, multi-line strings).

  3. 3

    Instant output

    Live conversion as you type (debounced). Convert button forces refresh. OK/Error status at the bottom with parser message.

  4. 4

    Swap I/O

    Swap input and output with one click, useful for round-trip tests. E.g. write YAML, convert to JSON, swap, convert to TOML, swap, you should get back to the original YAML (modulo TOML edge cases).

Three formats, three worlds

YAML, JSON and TOML cover overlapping but distinct use cases. JSON is the universal wire format for REST APIs and for app configs where the bracket verbosity is acceptable. YAML is the de facto standard for orchestrator manifests (Kubernetes, Ansible, Helm) and for CI/CD pipelines (GitHub Actions, GitLab CI, CircleCI), thanks to its indentation-based readability. TOML is the modern config format for ecosystems that want to avoid YAML's indentation ambiguity (Cargo for Rust, pyproject.toml for Python, Hugo). Converting across the three is frequent for engineers who cross stacks within the same project.

Operational privacy. Configuration files often contain sensitive information: secrets accidentally not removed, API keys, internal backend hostnames, the structure of a deployment model. Format conversion that requires uploading the file to a third-party service is a documented anti-pattern. Here the conversion happens directly in the browser, so the config content does not leave the machine.

Strict validation with error position. When the source is invalid, the tool reports line and column of the syntax error along with the underlying parser message. Particularly useful with YAML, where a wrong indentation can silently produce an incorrect data structure; and with TOML, where the explicit types (string vs datetime vs integer) generate clear errors which are nevertheless rare for those who do not know the spec by heart.

Glossary

Technical terms used on this page, briefly explained.

YAML #
YAML Ain't Markup Language. Indentation-based, human-readable data-serialization format. De-facto standard for orchestrator config (Kubernetes, Ansible) and CI/CD (GitHub Actions, GitLab CI, CircleCI).
JSON #
JavaScript Object Notation, RFC 8259. Universal wire format. Valid subset of YAML 1.2 (any JSON is also YAML).
TOML #
Tom's Obvious Minimal Language. Tom Preston-Werner, 2013. Spec 1.0.0 (2021). Modern config format for Rust (Cargo), Python (pyproject), Hugo. INI-like syntax with explicit type system.
Lossless roundtrip #
Property of a conversion: A -> B -> A produces the identical original A. JSON <-> YAML is lossless for simple data. TOML has lossy edge cases (complex datetime offsets, key ordering).

Frequently asked questions

Does TOML support all spec 1.0 types?
Subset. The custom parser/serializer covers: scalar key=value, [section], [a.b.c] dotted, inline tables, arrays, strings (quoted/raw single-line), integers, floats (including scientific), booleans, datetimes (parsed as ISO 8601 strings without smarts). Skipped: multi-line strings (triple quote), array of tables ([[...]]), complex datetime offsets, hex/octal/bin literals. For full TOML 1.0 spec a CLI tool with @iarna/toml works better.
Does YAML preserve comments?
No. Most mainstream YAML parsers handle comments as metadata, but the dump does not preserve them: in the YAML -> object -> YAML roundtrip the comments are lost. For workflows where the comments must remain (Helm configs, manifests annotated with the rationale of the choices) you need a CST-aware parser (Concrete Syntax Tree), typically in Python or in specialized YAML libraries.
Does JSON to YAML auto-generate anchors?
No. The YAML output is produced without anchors (&) or aliases (*). For datasets with circular references (rare in configs, common in some serialized ML pipelines) you need manual workarounds or to flatten the structure upfront.
Can I convert multi-document YAML (--- separator)?
Yes for parsing (js-yaml.loadAll). But the tool handles single-document in V1: if you paste multi-doc YAML, only the first one is parsed. For multi-doc we will extend with a dedicated tab in the future.
Does the JSON output have configurable indentation?
V1 defaults to 2 spaces. For other formats (4 spaces, tab, minified) use the dedicated JSON formatter in this realm after the conversion: paste the JSON output, choose the indent, reformat.
Does it work offline?
Yes. All parsers and serializers load on the first page hit; afterwards the conversion keeps working without a connection, useful in scenarios with intermittent or air-gapped networks.
Does the tool handle files larger than 1 MB?
Yes as long as the tab memory holds. For very large configs a CLI tool is more appropriate (yq for YAML, jq for JSON, tomlq for TOML, all with streaming processing): they handle gigabyte files without freezing the browser and integrate into automation pipelines.
Practical difference between YAML and TOML for app config?
YAML is better for complex nested configs (CI/CD pipelines, Kubernetes manifests with arrays of pods). TOML is better for flat configs with few sections and simple types (desktop app config, package metadata). YAML allows ambiguous indentation typos (a frequent source of bugs); TOML is stricter and therefore less error-prone.

Who builds these tools?

Maurizio Fonte, senior IT consultant with 20+ years in PHP, Laravel, unmanaged Linux infrastructure, applied cybersecurity and AI/LLM integration. Production backends, legacy code modernization, security audits, custom AI agents and MCP servers: the work behind every tool published here.

About Maurizio Fonte