YAML vs JSON Explained
YAML is the language of infrastructure config — Kubernetes manifests, GitHub Actions workflows, docker-compose files, Ansible playbooks — while JSON is the language of APIs. Converting between them should be trivial, but YAML hides silent traps: tabs that parsers reject outright, unquoted dates that turn into timestamps, 007 that quietly becomes 7, and yes and no that older parsers read as booleans. The free YAML ↔ JSON converter converts in both directions with auto-detect, pins errors to the exact line and column, and warns about the gotchas other tools ignore — entirely in your browser, with nothing uploaded and zero ads.
TL;DR — the short answer
Paste YAML or JSON into the in-browser YAML ↔ JSON converter: it auto-detects the direction and converts instantly — nothing is uploaded, no ads, no signup. YAML is the human-readable format behind Kubernetes manifests, GitHub Actions workflows, docker-compose files and Ansible playbooks; JSON is the strict machine format APIs speak. The tool warns about YAML's silent traps — tabs, 007 → 7, duplicate keys, unquoted dates, .inf → null — converts multi-document files to a JSON array, and offers server-free share links (keep secrets out of URL parameters).
What is YAML — and why do configs use it?
YAML (a data format designed to be written and read by humans: indentation instead of braces, comments with #, anchors and aliases for reusing blocks, and no ceremony around strings. JSON is stricter — no comments, no trailing commas, every string quoted — which makes it fast and unambiguous for machines, but miserable to hand-edit. That division of labor explains where each one lives: YAML is what you author, JSON is what software consumes.
Practically every infrastructure tool settled on YAML for its human-facing files: Kubernetes manifests, GitHub Actions and GitLab CI workflows, docker-compose files, Ansible playbooks, OpenAPI specifications, and application config files. Interest in converting between the two is steady — one industry analysis estimated roughly 2,900 monthly searches for “yaml to json” with very low ranking difficulty, and a separate builder case study put the wider “json to yaml” query family near 50k monthly searches combined (both are third-party estimates).
One fact simplifies everything: any valid JSON document is valid YAML 1.2. The YAML specification describes YAML as a natural superset of JSON, so a JSON blob pasted into a YAML parser just works — with one caveat for historians: YAML 1.1 is not a strict superset, so very old 1.1-era parsers can disagree.
How do you convert YAML to JSON (and back)?
Paste or drop your file into the YAML ↔ JSON converter and it detects the direction itself: JSON in means YAML out, YAML in means JSON out. Then adjust the output to taste — JSON indentation (2 or 4 spaces, tabs, or fully compressed), YAML indentation width, and a strict-vs-permissive JSON input toggle for inputs with trailing commas or comments. Copy the result, or download it as .json or .yaml.
Two features solve the problems that send people to converters in the first place. First, tab auto-fix: tabs in indentation are illegal in YAML, and the tool detects and repairs them instead of just failing. Second, multi-document conversion: files with several ----separated documents — the norm for Kubernetes manifests — normally make one-shot converters throw “expected a single document in the stream, but found more”; this one offers to convert every document into a JSON array. Errors, when they happen, are pinned to the exact line and column with a caret snippet, mirroring the parser's own format — e.g. bad indentation of a mapping entry (1:8).
Share links pass a conversion to a teammate through the URL — no server involved — but keep secrets out of them: URL parameters live in browser history. As a bonus, the converter doubles as a YAML validator: if your file converts cleanly, it is valid; if not, you get the exact line to fix.
What silently goes wrong when converting YAML?
The arithmetic of conversion is easy — maps become objects, sequences become arrays, scalars become typed values. The danger is the silent type changes: conversions that succeed but quietly alter your data. These are the traps a serious converter warns about:
| Gotcha | What happens | How to handle it |
|---|---|---|
| Tab indentation | Parsers reject it: “tab characters must not be used in indentation” (YAML 1.2 §6.1) | Use spaces, or let the tool auto-fix tabs |
| 007 | Becomes the number 7 in YAML 1.2 — but JSON forbids leading zeros, so “007” must be quoted going back | Quote it if you mean a string |
| yes / no / on / off | YAML 1.1 parsers read them as booleans; YAML 1.2 keeps them as strings | Quote them when the parser is old or unknown |
| Duplicate keys | js-yaml throws “duplicated mapping key”; PyYAML silently keeps the last | Treat a warning here as a bug in your file, not noise |
| Multi-document --- | One-shot converters error: “expected a single document in the stream, but found more” | Convert all documents to a JSON array |
| Unquoted dates | Some parsers read 2024-01-01 as a Date, emitting "2024-01-01T00:00:00.000Z" in JSON | Quote dates you mean as strings |
| .inf / .nan | Parse to Infinity/NaN — which JSON cannot represent, so they become null | Flag and replace them before shipping JSON |
| Anchors & aliases &a / *a / << | Resolved and flattened during parsing — references do not survive in JSON | Expect expanded output; merge keys may be dropped by default |
Two of these deserve special attention. The yes/no/on/off trap is a genuine version split: YAML 1.1's boolean list included y, n, yes, no, on, off and more, while YAML 1.2's core schema narrowed it to just true/false — and js-yaml v5 defaults to 1.2, so those words stay plain strings with 1.1 booleans as opt-in. And the date trap: unquoted 2024-01-01 reads as midnight UTC in older parser defaults, so your JSON quietly gains a T00:00:00.000Z suffix — the kind of change that passes every eyeball test and breaks a deployment.
Is it safe to paste configs into an online converter?
Think about what lives in config files: API keys, database passwords, cloud credentials, private tokens. Now look at the top-ranking converter pages: video ads playing in iframes, sticky ad banners, and “save online” or “save & share” features that by definition move your data to someone else's server — with no clear statement that conversion happens locally. Several popular converters process what you paste on their servers by default, for a job your browser does natively in milliseconds.
A browser-local tool removes the question entirely — and the claim is verifiable: open your Network tab while converting and you will see zero requests leave the page. Every ToolsOfWeb utility works this way. One honest caveat: even a client-side page is not a vault — keep secrets out of share-link URLs (they live in browser history) and remember that browser extensions can read page content. For anything truly sensitive, the safest converter is still the one on your own machine.
| Typical converters | ToolsOfWeb | |
|---|---|---|
| Directions | One direction per page — YAML→JSON and JSON→YAML live on separate URLs | Bidirectional with auto-detect, one page |
| Ads & popups | Video ads, sticky banners on the top-ranking pages | None. Ever. |
| Privacy | “Save online” features; no client-side claim on the page | 100% client-side — verifiable in the Network tab |
| Error reporting | Generic messages, or a validator link on another page | Pinned to line and column, with a caret snippet |
| Gotcha warnings | None — silent type changes pass through | Duplicate keys, dates, tabs, 007, .inf flagged inline |
| Multi-document files | Errors out on ----separated streams | Convert all documents to a JSON array |
FAQs
yaml to json online+
Paste your YAML into the converter and it becomes JSON instantly — no signup, no upload, no ads. The converter auto-detects the direction, so pasting YAML simply gives you JSON. Errors are pinned to the exact line and column, and gotchas like duplicate keys or tab indentation are flagged inline.
json to yaml online+
The same converter handles JSON to YAML — it auto-detects JSON input and emits clean YAML with configurable indentation. Since every valid JSON document is also valid YAML 1.2, this is the safest direction: nothing is lost except formatting preferences.
convert yaml to json+
The conversion itself is arithmetic your browser does in milliseconds: YAML maps become JSON objects, sequences become arrays, scalars become typed values. The hard part is YAML’s silent traps — unquoted dates, 007, tabs — which is why a good converter warns about them. The ToolsOfWeb converter is bidirectional with auto-detect, so one paste handles either direction.
is json valid yaml+
Yes — for YAML 1.2. The spec describes YAML as “a natural superset of JSON”: any valid JSON document is valid YAML 1.2, and modern parsers read it without complaint. Nuance: YAML 1.1 is not a strict superset, so very old 1.1-era parsers can disagree — but every modern parser defaults to 1.2 behavior.
why are tabs not allowed in yaml+
The YAML 1.2 spec forbids them outright — “tab characters must not be used in indentation” — and parsers like js-yaml throw exactly that error, because tab width varies between editors and would break YAML’s indentation-based structure. Spaces are unambiguous: use them, or let the converter’s tab auto-fix repair your paste.
yaml vs json which is better+
Neither — they solve different problems. YAML is for humans: comments, indentation, anchors, and readability make it the default for config files you edit by hand. JSON is for machines: strict, compact, fast to parse — which is why APIs speak it. The common pattern is authoring in YAML and converting to JSON where a strict machine-readable format is required.
yaml online validator+
The converter doubles as a validator: if your YAML parses and converts cleanly, it is valid. When it is not, errors are pinned to the exact line and column — for example “bad indentation of a mapping entry (1:8)” with a caret showing where the parser choked.
how to convert kubernetes yaml to json+
Paste the manifest into the converter and copy the JSON output. If your file holds several documents separated by --- (common when deploying multiple resources), most one-shot converters error out — the ToolsOfWeb converter offers “convert all documents” and emits a JSON array, one element per document.
Is the data I paste uploaded anywhere?+
With the ToolsOfWeb converter, no: it runs entirely in your browser — the parsing library is under 18 kB — and you can verify it in your Network tab: zero requests while converting. Configs routinely contain API keys, tokens, and connection strings, while the top-ranking converters pair your paste with “save online” features and ad networks. One honest caveat: keep secrets out of share-link state — URL parameters live in browser history.
Why do the words no, yes, on, and off sometimes become true or false?+
It is a YAML version split. YAML 1.1 treated y/n/yes/no/on/off (and more) as booleans; YAML 1.2 narrowed booleans to just true/false in its core schema. The true/false behavior you are seeing comes from 1.1-era parsers like PyYAML. js-yaml v5 — the library behind this converter — defaults to the 1.2 core schema, where yes, no, on, and off stay plain strings; 1.1-style booleans are opt-in. When in doubt, quote the word: “yes” is a string everywhere.
For more free utilities, see ToolsOfWeb's JSON Formatter and JSON to CSV Converter, or read the JSON Formatter guide and the JSON to CSV Converter guide.