Tiny Tiny Tools

Local browser utility · Examples and limits included

YAML to JSON

Convert YAML to JSON in your browser: nested mappings, sequences, block scalars and flow collections, with anything outside the subset reported by line.

Booleans follow YAML 1.2, so unquoted no stays the string “no” rather than becoming false. Anything outside the supported subset — anchors, aliases, merge keys, tags — is reported by line rather than guessed at.

What the result contains
What This Tool Provides
Convert YAML configuration into JSON in your browser: nested mappings, sequences, quoted and plain scalars, comments, block scalars and inline flow collections. This is a documented subset of YAML rather than a full implementation, and anything outside it — an anchor, an alias, a merge key, a type tag — is reported with its line number instead of being silently dropped or guessed at.
  • JSON at your choice of 2-space, 4-space, or minified indentation
  • Nested mappings, sequences, and inline flow collections resolved
  • Block scalars with literal and folded styles, including chomping indicators
  • A per-line report of anything outside the supported subset
How to Use This Tool
  1. Paste the YAMLA config file, a manifest, a workflow definition — anything indentation-based.
  2. Pick the output shapeTwo spaces, four spaces, or minified for pasting into a request body.
  3. Read the report firstAnything the parser could not fully honor is listed by line before you copy. An empty list means the whole file was understood.
How It Works
The file is split into lines with their indentation measured, comments outside quotes are removed, and the result is parsed by recursive descent: a line deeper than its parent opens a nested mapping or sequence, and a line at the same depth continues the current one. Scalars are resolved by their plain form — quoted values stay strings, true and false become booleans, tilde and null become null, and anything matching an integer or float pattern becomes a number. Block scalars are handled separately because they need the original blank lines, so the reader walks the raw text for those rather than the comment-stripped view.
Worked Examples
A nested config with a sequence
Input
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
Output
{
  "services": {
    "web": {
      "image": "nginx:latest",
      "ports": ["8080:80"]
    }
  }
}
Indentation becomes nesting, and the dash sequence becomes a JSON array. The quoted port stays a string, which matters — unquoted it would still be a string here, but some parsers read 8080:80 as a sexagesimal number.
A literal block scalar keeps its newlines
Input
script: |
  set -e
  npm run build
Output
{
  "script": "set -e\nnpm run build\n"
}
The pipe preserves line breaks; a greater-than sign would fold them into spaces instead. Writing |- strips the final newline.
The Norway problem, reported rather than repeated
Input
country: no
Output
{
  "country": "no"
}

Line 1: "no" is a string here, following YAML 1.2. A YAML 1.1 parser would read it as a boolean.
Unquoted no stays a string, and the difference from YAML 1.1 is flagged, because the same file parsed elsewhere may not agree.
The Norway Problem, and Why Booleans Are Hard
YAML 1.1 treated a generous set of words as booleans: not just true and false, but yes, no, on, off, y and n, in several capitalizations. YAML 1.2, published in 2009, narrowed that to true and false only. Both versions are still in the wild, which means the same file can parse differently depending on which library reads it.
The famous consequence is the Norway problem. A list of country codes written unquoted — GB, FR, NO, DE — comes back from a YAML 1.1 parser with false sitting where NO should be, because NO is one of the 1.1 boolean spellings. The same trap catches a config listing ports as on and off, a spreadsheet column of Y and N answers, and anywhere a two-letter code happens to collide.
This tool follows YAML 1.2, so unquoted no stays the string "no". But being right is not enough when the file will be read by something else, so any value that would have been a boolean under 1.1 is reported by line. Quoting it — writing "no" rather than no — makes the file unambiguous under every parser, which is the actual fix.
What This Parser Supports, and What It Reports
Full YAML is a large specification with a genuine security history — the reason so many languages ship a deliberately restricted "safe load" is that unrestricted YAML can be made to construct arbitrary objects. What this page implements is the shape of YAML that configuration files actually use, and it says so rather than implying more.
Supported: mappings nested by indentation, sequences of scalars and of mappings, single- and double-quoted strings with their different escaping rules, comments outside quotes, the literal and folded block scalar styles with chomping indicators, inline flow collections in both bracket and brace form, explicit nulls, and a leading document marker.
Reported rather than resolved: anchors and aliases, merge keys, type tags, complex mapping keys, second and subsequent documents, tabs used for indentation, and duplicate keys. In each case the line number is given. The reasoning is the same one behind the CSV tools — a config file about to be deployed is the last place a silently dropped key belongs.
Coverage of the supported subset
ConstructExampleStatus
Nested mappingserver: then indented host:Supported
Sequence of mappingsA dash followed by key: valueSupported
Block scalarA pipe or greater-than, with - or +Supported
Flow collectionSquare brackets or braces inlineSupported
Anchor and aliasAmpersand and asterisk labelsReported by line, not resolved
Merge keyA double angle bracket keyReported by line, not expanded
Type tagOne or two exclamation marksReported by line, then ignored
Multiple documentsA second triple-dash markerFirst document only, reported
Why Indentation Errors Are So Costly
YAML puts structure in whitespace, which makes it pleasant to read and unusually easy to get subtly wrong. A key indented two spaces too far does not produce an error — it produces a valid file with a different meaning, in which that key is now a child of the wrong parent. The application starts, the setting is simply never read, and the failure surfaces much later as behavior nobody can explain.
Tabs are the other classic. YAML forbids a tab as indentation, and an editor configured to insert tabs will produce a file that some parsers reject outright and others handle inconsistently. Any tab used for indentation is flagged here by line, because the character is invisible and staring at the file will not reveal it.
When the thing you need is not the whole structure but one value repeated across a large manifest — every image tag, every port, every hostname — testing a pattern against the file finds them faster than scrolling. And when a config holds a long list of similar entries that somebody non-technical has to review, flattening the converted JSON into a table turns it into something openable in a spreadsheet.
This is the strongest practical argument for converting to JSON as a check. JSON makes structure explicit with braces, so the moment you see the converted output, a key sitting at the wrong depth is obvious in a way it never is in the YAML source. Pasting the result into a formatter with a structure view makes the nesting easier still to scan.
JSON, YAML, and Choosing Between Them
Every JSON document is valid YAML — YAML 1.2 was defined as a superset — so converting in this direction always succeeds in principle. The other direction does not: JSON has no comments, no anchors, no multiple documents, and no block scalars, so a YAML file using those loses something on the way across. Comments are the loss people feel most, because a config file’s comments are frequently the only documentation of why a setting is what it is.
That asymmetry is worth remembering when choosing a format for a new project. YAML is better for files humans edit and annotate: Kubernetes manifests, CI pipelines, application config. JSON is better for anything a machine writes or transmits, where comments have nowhere to go and the strict grammar prevents whitespace ambiguity. Converting between them is a reading aid, not a migration strategy.
Once the config is JSON, the rest of a debugging session usually follows familiar paths. Config values arriving Base64-wrapped are common in Kubernetes secrets in particular, where decoding the value reveals what is actually being mounted. Comparing a working environment against a broken one is a line diff rather than a read-through. And any secret you find sitting in plain text in a committed config should be replaced rather than reused — generate a new one and put the old one out of service.
Important Edge Cases
  • Only the first document in a multi-document file is converted, because JSON has no multi-document equivalent. The presence of others is reported.
  • A duplicate key keeps the later value, matching most YAML parsers, and the collision is reported so it is not mistaken for a merge.
  • An anchor such as &defaults labels the block beneath it, so the structure still parses; only the alias referring to it is left unresolved.
  • Single-quoted strings treat backslashes literally and use two single quotes for one; double-quoted strings process escape sequences. Both are handled, and the difference surprises people.
  • An integer too large to be represented exactly is kept as a string rather than silently rounded.
Limitations
  • This is a documented subset of YAML, not a complete implementation. Anchors, aliases, merge keys, tags, and complex keys are reported rather than resolved.
  • Comments are discarded, because JSON has nowhere to put them. Converting a heavily annotated config loses its annotations.
  • Only the first document of a multi-document file is converted.
  • Date and timestamp values are kept as strings; there is no automatic conversion to a date type, which YAML 1.1 parsers sometimes perform.
  • Input is capped at 500,000 characters, so a very large manifest is better handled by a dedicated library.
Input handling
Private Browser Processing
The YAML you paste is parsed in your browser by code shipped with this page. Nothing is uploaded, stored, or logged, and configuration files frequently contain secrets — which is exactly why this conversion happens locally.
Google Analytics records page visits and whether a tool finished or failed, but these tool implementations do not send field values, generated passwords, QR payloads, uploaded QR images, or camera frames to analytics or a Tiny Tiny Tools processing endpoint.
See the Privacy Policy for site-wide details.
Questions About This Tool
Why did my value "no" not become false?
Because this follows YAML 1.2, where only true and false are booleans. YAML 1.1 also treated yes, no, on and off as booleans, which is the origin of the Norway problem. The difference is flagged by line; quoting the value removes all doubt.
Does it support anchors and aliases?
It does not resolve them. A file using an anchor still parses — the anchor labels the block beneath it — but an alias referring to that anchor is left as text and reported with its line number rather than expanded.
What happens to my comments?
They are discarded, because JSON has no comment syntax. This is the main thing lost converting YAML to JSON, and it is worth keeping the YAML source rather than treating the JSON as a replacement.
Can it convert a multi-document file?
Only the first document. JSON has no equivalent of the triple-dash separator, so the rest is left alone and the presence of further documents is reported.
Is JSON really valid YAML?
Yes. YAML 1.2 was defined as a superset of JSON, so any JSON document is also a YAML document. The reverse does not hold, which is why converting this direction is the safe one.
Is my config file sent anywhere?
No. It is parsed by your own browser. That matters more here than on most pages, because config files routinely contain credentials — and you can confirm the absence of any request in the network tab.