What this parser accepts
The YAML side is a small hand-written parser rather than a library, which keeps the page dependency-free and means the supported surface is worth stating exactly. It reads block mappings nested by indentation, block sequences introduced with - , mappings inside sequence items (- name: x with further keys aligned under it), inline sequences [a, b] and inline mappings {a: 1}, # comments outside quotes, both quoting styles, plain scalars that wrap across lines, and block scalars with | and > including the - and + chomping indicators. A leading --- is skipped. Tabs used for indentation are rejected, which is not this parser being fussy — the YAML spec forbids them.
What it refuses, and why that matters
Anchors (&base), aliases (*base), merge keys (<<:), type tags (!!str, !Ref), explicit complex keys (? ) and more than one document per file are all unsupported. This is the limit you are most likely to hit in practice, because the reuse pattern is everywhere in real config:
x-common: &common
restart: always
logging: { driver: json-file }
services:
api:
<<: *common
image: api:latestFeed that in and *common comes back as the four-character string, and the merge key becomes a literal key named <<. The result parses without complaint and is wrong. A warning appears when the input contains something that looks like an anchor, but do not lean on it. A Kubernetes bundle with --- separating several manifests is the other common failure: everything after the first document is read as if it were part of it, usually producing an indentation error rather than a clean message. For either case you want a real YAML library — yq, or js-yaml in a scratch script.
Type inference, and the values it gets wrong on purpose
Unquoted scalars are resolved against the YAML 1.2 core schema. true and false are booleans; null, ~ and an empty value are null; integers, decimals, exponents and 0x hex are numbers; everything else is a string. Note what that excludes: yes, no, on and off were booleans in YAML 1.1 and are plain strings here, which matches modern parsers but not every old one. If a tool downstream reads no as false, quote it and stop relying on the coincidence.
Two more traps, both of which produce valid output that means the wrong thing. A zip code or account number written 01234 keeps its leading zero as a string, because treating it as a number would silently drop the zero. And a version written 1.10 is a number, so it becomes 1.1 and the two are now the same version. Quote anything that is an identifier rather than a quantity.
Going the other way
Every JSON document is valid YAML, so that direction always succeeds. The output quotes any string that would otherwise be re-read as something else — "true", "123", "1.0", anything starting with a structural character — so the round trip preserves types. Strings containing newlines are written as | block scalars. Empty collections come out as [] and {}. Key order follows JavaScript object insertion order, with one wrinkle worth knowing: keys that look like non-negative integers get hoisted to the front by the language itself, so {"b":1,"2":2} emits 2 before b. Nothing can be done about that at this layer.
Where to stop trusting it
Treat this as a reading aid, not as part of a pipeline. It is good for answering "what shape is this file" and "which line is the indentation wrong on" without leaving the browser, and the input never goes anywhere — the parse happens in the tab, with no upload. It is not good for converting a manifest you are about to apply. When the output will be fed to something that acts on it, run it through a full implementation first and compare.
Questions people ask
The indentation looks fine to me but it errors anyway.
Almost always a tab that a text editor is rendering as spaces, or two keys at the same logical level that are indented by different amounts. Turn on whitespace rendering in your editor and look at the reported line and the one above it. YAML forbids tabs for indentation entirely, so a single tab anywhere in the leading whitespace is fatal regardless of how it looks.
A value I need as a string turned into a number.
Unquoted scalars get type-inferred, so 123 is an integer and 1.10 is the number 1.1. Quote anything that is an identifier rather than a quantity: version strings, zip codes, account numbers, phone numbers, anything with a leading zero. Going from JSON to YAML the quotes are added for you, because the converter knows the value started as a string.
My docker-compose file came out with *common as a string.
That is the anchor and alias limitation. This parser does not resolve YAML references, so an alias survives as the literal text and a merge key becomes a key named <<. The structure will look plausible and be wrong. Use yq or js-yaml for files that use the reuse pattern; there is no partial workaround worth suggesting.
Can I convert several documents separated by --- at once?
No. Document separators are stripped and everything is treated as one document, which usually ends in an indentation error and occasionally in a silently merged mess. Split the file and convert one document at a time, or use a parser with multi-document support.