Convert JSON ↔ YAML — and see exactly what changes.

It converts JSON to YAML or YAML to JSON in your browser, and then tells you what the conversion cost. Comments, anchors and aliases, merge keys, timestamps, multi-document streams and integers too large for JavaScript to hold exactly cannot survive the trip — so each one is reported as a named warning or note next to the output instead of disappearing quietly.

YAML 1.2, via js-yaml 4 and its default (core) schema — the same reader used by most modern JavaScript tooling. That matters because YAML 1.2 dropped the YAML 1.1 boolean spellings: no, yes, on and off are plain strings here, and only true and false are booleans. PyYAML, Ruby's Psych and older Kubernetes tooling still follow YAML 1.1, so the reference table on this page pins the values where the two versions disagree.

A YAML 1.1 parser reads the unquoted scalar NO as the boolean false, so a country list containing Norway's ISO code turns into a list containing false. The same trap catches ON, OFF, YES, Y and N. This converter follows YAML 1.2, so those stay strings — and it flags every one it sees so you know a YAML 1.1 tool downstream would disagree. In the other direction it quotes them on output ("NO" becomes 'NO'), which is what keeps the file safe to feed to PyYAML.

No. Parsing, conversion and reporting all run 100% client-side in your tab — there is no server, no account and no logging. You can safely paste production manifests, CI configs and files containing internal hostnames or secrets.

They are lost, and the tool says so. JSON has no comment syntax, and preserving comments through a round trip would require a comment-aware syntax tree rather than a value parser — that is a deliberate non-goal here. If you need comments to survive, edit the YAML directly instead of round-tripping it through JSON.

They are expanded in place. An anchor (&defaults) marks a value; an alias (*defaults) reuses it. JSON has neither, so every alias becomes a full copy of the anchored value — the document means the same thing, but it is longer and the sharing is gone. Merge keys (<<:) are expanded the same way, with the inherited keys written out in full. A recursive alias, where a node contains itself, cannot be represented in JSON at all and is reported as an error rather than crashing the page.

JavaScript holds numbers as IEEE-754 doubles, so integers beyond 2^53 − 1 (9007199254740991) cannot be represented exactly. 9007199254740993 becomes 9007199254740992 the moment it is parsed — by this tool, by JSON.parse in your own code, and by any other browser-based converter. The difference is that this one warns you and quotes the original digits. If the value is an ID rather than a quantity, keep it as a quoted string.

Paste the manifest, keep the direction on YAML → JSON, and copy the output. kubectl patch --type=merge -p accepts a JSON document, and a multi-document manifest (several resources separated by ---) becomes a JSON array here, which kubectl will not accept as a patch — split it and convert one resource at a time. Quantities such as 256Mi and 500m stay strings in both formats, which is what Kubernetes expects.

Not while it uses the shorthand tags. !Ref, !GetAtt and !Sub are CloudFormation-specific YAML tags, not part of the standard schema, so a standards-compliant parser rejects them — this tool says exactly which tag it choked on and where. Rewrite them in their long form (Ref: BucketName instead of !Ref BucketName) and the template converts.

Yes, with one unavoidable exception. Key order is preserved by default, and "Sort keys" sorts every level when you want a stable diff. The exception is integer-like keys: JavaScript objects always enumerate keys such as "1" and "2" first, in ascending numeric order, before any other key — whatever order they were written in, and whether or not they were quoted. The tool warns when your document contains them.