I spent an afternoon last year debugging a Helm values file that a colleague swore was correct. Every key looked right. The service refused to start. The culprit turned out to be four characters: NO as a country code, unquoted, in a list of regions. The YAML parser read it as the boolean false, the template rendered false into a header, and the request was rejected downstream with an error message that mentioned neither YAML nor Norway. That bug is famous enough to have a name - the Norway problem - and it is only one of a family of surprises waiting in a format most of us treat as "JSON with nicer whitespace."
TL;DR: The YAML to JSON Converter parses a YAML document and prints the equivalent JSON, resolving anchors, aliases, merge keys, and block scalars along the way. Seeing your config as JSON shows you exactly what the parser decided your values mean - which types it inferred, which references it expanded - before that interpretation reaches a cluster. It runs entirely in your browser.
Converting YAML to JSON is not only a format change. It is the fastest available audit of what your configuration actually contains. JSON has no comments, no anchors, no implicit typing beyond what the syntax states outright, so the JSON view of a manifest is the resolved, unambiguous version of it. This guide covers how YAML maps onto JSON, the type and reference behaviours that cause real incidents, and how to use the converter when you are debugging a config, scripting against a manifest, or writing a test fixture.
What does converting YAML to JSON actually do?
The relationship is defined, not incidental: the YAML 1.2 specification states that YAML is a superset of JSON, so every JSON document is already valid YAML. YAML and JSON describe the same three things: mappings of keys to values, ordered sequences, and scalars. Conversion walks the YAML document and emits each construct in its JSON equivalent. A block mapping becomes an object. A block sequence becomes an array. A scalar becomes a string, number, boolean, or null, depending on how the YAML core schema resolves it.
The structural part is uninteresting because it is mechanical. The interesting part is everything YAML can express that JSON cannot, because that is where the converter has to make a decision on your behalf:
| YAML feature | What JSON gets | Why it matters |
|---|---|---|
Comments (# ...) |
Dropped | JSON has no comment syntax; documentation in your config does not survive |
Anchors and aliases (&base, *base) |
Expanded copies | JSON has no reference syntax, so shared blocks are duplicated |
Merge keys (<<: *base) |
Flattened into the object | Explicit keys override merged ones, per the merge-key spec |
| Block scalars (` | , >`) |
A single string with escapes |
Multiple documents (---) |
An array of documents | A Kubernetes bundle becomes a JSON array, one element per resource |
| Implicit typing | Resolved types | Unquoted 8080 becomes a number, true a boolean, null a null |
That last row is the one worth staring at. JSON forces every value to declare its type through syntax: quotes mean string, bare digits mean number. YAML infers type from the shape of the text. Converting to JSON makes the inference visible. If you expected a version string and JSON shows you 1.1 where the YAML said 1.10, you have found a bug you would otherwise have shipped.
Why YAML's implicit typing causes real outages
The YAML 1.2 core schema resolves an unquoted scalar by pattern. Digits become integers. Digits with a decimal point or exponent become floats. true and false become booleans. null and ~ become null. Everything else is a string.
That sounds tidy until you meet the values that look like one type and are meant as another:
- Ports and IDs.
port: 08080is not the number 8080. A leading zero makes it an invalid integer under the core schema, so most parsers hand back the string, and some older ones interpret it as octal. Postal codes, phone numbers, and account IDs with leading zeros have the same problem. - Versions.
version: 1.10is the float1.1. The trailing zero is gone, and no parser warns you. Compare that against a container tag and the lookup fails. - Country and language codes. Under YAML 1.1 - which PyYAML still follows by default, along with a lot of Ruby and older Java tooling -
y,n,yes,no,on, andoffare booleans.NO,ON, andNAare perfectly ordinary two-letter codes in the real world. - Times and sexagesimals. YAML 1.1 also parses
12:30as a base-60 number, which is 750. Cron-like or duration-like strings can vanish into integers.
Each of these is a silent data corruption, not a parse error. The document is valid, the pipeline is green, and the value is wrong. The converter's Keep strings option exists for exactly this class of investigation: switch it on and every plain scalar comes back as a string, so you can compare the two conversions side by side and see precisely which values the parser was reinterpreting. Whatever the JSON shows without that option is what your production parser is most likely doing today.
The fix in your source YAML is always the same: quote anything whose meaning is textual. port: "8080", version: "1.10", region: "NO". Quotes cost nothing and remove the entire category of bug. If you generate YAML from JSON rather than writing it, the JSON to YAML Converter applies that quoting automatically for ambiguous values.
How anchors, aliases, and merge keys convert
Anchors are YAML's answer to repetition. You mark a node with &name, then reference it later with *name:
defaults: &defaults
restartPolicy: Always
terminationGracePeriodSeconds: 30
web:
<<: *defaults
replicas: 3
worker:
<<: *defaults
terminationGracePeriodSeconds: 120
JSON has no way to say "the same value as over there." So the converter expands every reference into a full copy. The output above becomes three objects, each carrying its own restartPolicy, and the JSON is longer than the YAML that produced it. That is not a flaw in the conversion - it is what the YAML means, written out.
The merge key << deserves its own note because its precedence rule is easy to get backwards. Keys written explicitly in the child mapping win over keys pulled in by the merge. In the example, worker ends up with a grace period of 120, not 30, regardless of whether the merge line appears above or below the explicit key. The converter implements that rule, so the JSON shows you the effective, post-merge configuration - which is usually the thing you actually wanted to inspect.
Two practical uses follow from this. First, when a config uses heavy anchoring, converting to JSON is the quickest way to answer "what does this environment actually resolve to?" without running the deploy. Second, if an alias has no matching anchor - a common result of splitting one big file into several - the converter reports it as an error with the line number, rather than silently producing a null.
How block scalars convert
YAML has two ways to embed multi-line text, and they behave differently:
- Literal (
|) keeps every line break exactly as written. Use it for shell scripts, PEM certificates, SQL, and anything whitespace-sensitive. - Folded (
>) joins consecutive lines with a single space and treats a blank line as a paragraph break. Use it for prose that you want wrapped in the source file but joined in the value.
Both accept a chomping indicator that controls trailing newlines. The default, called clipping, keeps exactly one trailing newline. A minus (|-) strips all trailing newlines. A plus (|+) keeps every one of them.
In JSON, all of this collapses into one string with \n escapes. That is another reason the JSON view is useful: it is unambiguous. A | block whose last line was accidentally indented, or a > block that fold-joined two lines you meant to keep separate, is obvious in JSON and nearly invisible in YAML. The converter also handles the case that catches naive implementations - a # character inside a literal block is content, not a comment, which matters the moment you embed a shell script starting with a shebang.
How to use the YAML to JSON Converter
Step 1: Paste the document
Paste any YAML into the input panel: a Kubernetes manifest, a docker-compose.yml, a GitHub Actions workflow, an Ansible playbook, a .gitlab-ci.yml, or an application config. Multi-document files with --- separators are fine - each document is parsed independently. Click Load Sample to start from a realistic Deployment that exercises nested maps, sequences, an empty collection, and a literal block scalar.
The one thing that will not parse is indentation with tab characters. YAML forbids tabs outright, and the converter says so with the offending line number rather than guessing. Editors that insert a tab on Enter are the usual source; most have a "convert indentation to spaces" command that fixes the whole file at once.
Step 2: Choose the output shape
Pick 2 spaces, 4 spaces, or Minified. Minified is what you want when you are about to paste the result into a curl body or an environment variable. Indented output is what you want when a human has to read it.
Sort keys rewrites the object keys alphabetically at every level. This is invaluable when comparing two versions of a config: two files that differ only in key order produce identical sorted JSON, so a diff shows only real changes. Feed both outputs into the JSON Diff tool and you get a precise structural comparison instead of a line-by-line one.
Keep strings disables scalar coercion, as described above. Use it when you want to see the raw text of every value, or when a downstream consumer treats everything as a string anyway.
Step 3: Convert and read the errors
Click Convert. If the document is well-formed, the JSON appears below along with the line count, key count, byte size, and - for multi-document streams - how many documents were found.
If it is not well-formed, the error names the line. The messages cover the failures that actually happen in practice: tabs used for indentation, a line indented inconsistently with its siblings, an unterminated quoted string, an alias with no anchor, a merge key pointing at something that is not a mapping. A line number turns a five-minute hunt into a five-second fix.
Step 4: Copy, download, or keep going
Copy the JSON to your clipboard or download it as a .json file. From there, common next steps are pretty-printing and validating with the JSON Formatter, generating types for a config loader with JSON to TypeScript, or deriving a contract for CI validation with the JSON Schema Generator.
Real workflows this fits
Debugging a manifest that "looks fine"
When a deployment behaves unexpectedly and the YAML reads correctly, convert it. Nine times out of ten the JSON shows the problem immediately: a value that became a boolean, a nested key one level shallower than intended because of a stray space, an anchor that expanded to something stale. The JSON view removes the whitespace ambiguity that made the bug invisible.
Scripting against configuration
Shell and Node scripts handle JSON natively; YAML needs a dependency. When I need to pull every image tag out of a bundle of manifests, converting to JSON first and piping through jq is faster than adding a YAML library to a throwaway script. The converter's multi-document support matters here - a Kubernetes bundle of six resources becomes a JSON array you can iterate.
Building test fixtures
Integration tests often need a config object rather than a config file. Converting the real manifest to JSON gives you a fixture that is guaranteed to match production shape, which is a far better starting point than an object you typed from memory. Pair it with JSON to TypeScript and your fixture comes with types.
Reviewing configuration in a pull request
Diffs of heavily anchored YAML are hard to read because a one-line change to an anchor silently changes every consumer. Converting both versions with Sort keys enabled and diffing the JSON shows the true blast radius: every resolved value that changed, not just the line that was edited.
Migrating between tools
Plenty of platforms accept JSON but not YAML, or vice versa. Converting is usually the whole migration. When you need to go back the other way - JSON in hand, YAML required - the JSON to YAML Converter closes the loop, and the YAML Validator confirms the result parses before you commit it.
YAML and JSON compared
| Dimension | YAML | JSON |
|---|---|---|
| Comments | Yes | No |
| Human editing | Indentation-based, easy to skim | Punctuation-heavy, verbose |
| Machine parsing | Slower, larger parsers, more edge cases | Fast, tiny parsers everywhere |
| Type inference | Implicit, schema-dependent | Explicit from syntax |
| References | Anchors, aliases, merge keys | None |
| Multiple documents per file | Yes, via --- |
No |
| Typical home | Config files, CI pipelines, manifests | APIs, data interchange, storage |
YAML 1.2 is formally a superset of JSON, so every JSON document is already valid YAML. The reverse is not true, which is why converting YAML to JSON is a lossy operation in exactly one direction: comments and reference structure are discarded, while data is preserved. If your YAML has comments you care about, keep the YAML as the source of truth and treat the JSON as a derived artifact.
Privacy: why this runs in your browser
Config files are among the most sensitive plain-text artifacts a team has. They carry internal hostnames, cluster names, registry paths, service accounts, database identifiers, and - despite everyone's best intentions - the occasional credential that has not made it into a secret manager yet.
The converter is client-side JavaScript. Your document is parsed in the page, the JSON is produced in the page, and no request carries your data anywhere. Load the tool once and it keeps working with the network off, which is a reasonable habit for anything you paste a manifest into. This is the same principle behind every tool on the site, and the reasoning is spelled out in the guide on data privacy in online tools. If you are assembling a general-purpose browser toolkit, the web developer toolkit guide covers what else belongs in it.
Limitations worth knowing
No converter that fits in a browser tab implements every corner of the YAML specification, and it is more useful to be specific about the edges than to imply there are none.
Complex mapping keys - the explicit ? key form where the key is itself a sequence or mapping - are not supported, because JSON object keys must be strings. Type tags such as !!binary or custom !MyType directives are not interpreted; the value comes through as text. The special float values .inf, -.inf, and .nan are preserved as strings, since JSON has no literal for them and silently converting to null would lose more information than it saves. Directives such as %YAML 1.2 are ignored rather than acted upon.
None of these appear in ordinary Kubernetes, Compose, Actions, or Ansible files. If you hit one, you are working with a document written for a specific language's YAML library, and that library's own dumper is the right tool.
FAQ
How do I convert YAML to JSON online?
Paste your YAML into the input panel and click Convert. The parser reads the document, resolves anchors and block scalars, and prints formatted JSON you can copy or download. Everything happens in your browser, so no file is uploaded.
Is JSON a subset of YAML?
Yes. YAML 1.2 was redefined as a strict superset of JSON, so any valid JSON document is also valid YAML. The reverse is not true: YAML adds comments, anchors, block scalars, multiple documents per file, and non-string keys, none of which JSON can express directly.
How are YAML anchors and aliases converted to JSON?
JSON has no reference syntax, so each alias is expanded into a full copy of the value its anchor defines. A config that reuses a defaults block three times produces three identical JSON objects. The output is therefore larger than the YAML source but semantically identical.
What happens to merge keys like the double angle bracket?
The referenced mapping is merged into the current object. Keys written explicitly in the child mapping win over merged keys, which matches the behaviour of the YAML merge-key specification and of Kubernetes and Ansible tooling.
Why did my YAML fail with a tabs error?
YAML forbids tab characters for indentation - the specification allows only spaces. Editors that insert tabs on Enter are the usual cause. Convert the leading tabs to spaces, which most editors can do for a whole file at once, and the document will parse.
Can I convert a multi-document YAML file with document separators?
Yes. Each document between the separator markers is parsed independently and the result is a JSON array with one element per document, in source order. A single-document file returns the object itself, not a one-element array.
Will port numbers and version strings keep their type?
Plain scalars are resolved by the YAML core schema, so an unquoted 8080 becomes the number 8080 and an unquoted 1.10 becomes 1.1. Quote the value in your YAML to keep it a string, or switch on the Keep strings option to turn off all scalar coercion.
How do literal and folded block scalars convert?
A literal block keeps every newline, so it becomes a JSON string with escaped line breaks. A folded block joins consecutive lines with a space and treats blank lines as paragraph breaks. Chomping indicators are respected: a minus drops the trailing newline and a plus keeps every trailing blank line.
