Search DevTools

Jump to any tool or page

YAML to JSON Converter

Convert YAML to JSON and JSON back to YAML as you type, with anchors resolved and parser errors reported inline.

YAML

paste or load a sample

JSON

The converted document appears here as you type.

Send toJSON Formatter

About YAML and JSON conversion

Every valid JSON document is also a valid YAML 1.2 document, so JSON → YAML is always lossless. The other direction is not: YAML carries features JSON has no way to express, and the conversion has to resolve them. This tool parses with the yaml library’s YAML 1.2 core schema, entirely in your browser — nothing is uploaded.

What changes on the way to JSON

  • Comments disappear. JSON has no comment syntax, so every # line is dropped. Converting back will not restore them.
  • Anchors and aliases are expanded. An &defaults anchor referenced by *defaults or merged with << becomes a full copy at every use site, so the output is larger and the shared identity is gone.
  • Multi-document streams collapse. A file split by --- — a Kubernetes manifest bundle, typically — has no single-value JSON equivalent, so multiple documents come out as a JSON array.
  • Non-string keys are stringified. YAML allows true, numbers, or whole maps as mapping keys; JSON object keys are always strings.

Type coercion gotchas

  • YAML 1.1 booleans. The older spec — still what Python’s PyYAML, Ruby’s Psych, and many CI runners implement by default — reads yes, no, on, and off as booleans. YAML 1.2 recognises only true and false, so the same file can mean different things to two parsers.
  • The Norway problem. Under YAML 1.1 the country code NO parses as the boolean false. So do N, Y, and ON. Quote them.
  • Version strings become floats. An unquoted version: 1.10 is the number 1.1, and the trailing zero is lost forever. Leading-zero values like 08 are read as octal by YAML 1.1 and reject 8 and 9 as digits.
  • Sexagesimal numbers. YAML 1.1 treats colon-separated digits as base 60, so a build time of 12:30 arrives as 750. Ports written as 80:80 in a Compose file are the classic casualty.
  • Dates and timestamps. YAML 1.1 auto-resolves 2026-01-31 to a date object. JSON has no date type, so it serialises back as an ISO string — usually with a time component you did not write.

Tip: when a YAML value is meant to stay text — version numbers, country codes, ports, phone numbers, git SHAs, anything with a leading zero — wrap it in quotes. Round-tripping through this converter is a quick way to see which of your values a parser is quietly retyping.

Data Transformation

About YAML to JSON Converter

Convert YAML to JSON and back in the browser, including multi-document streams and anchors. The conversion is not purely cosmetic: YAML carries typing rules that JSON does not, so this tool parses under the YAML 1.2 core schema and shows you what the values actually became rather than what they look like.

Related Data Transformation tools

JSON FormatterImage to JSONPII RedactorSheet to JSONJSON to CSV/XLSX

Frequently asked questions

Why did my country code NO turn into false?
That is the Norway problem, and it comes from YAML 1.1, where the unquoted tokens yes, no, on, off, y and n are all booleans. A list of country codes containing NO parses as false under those rules. YAML 1.2 narrowed booleans to true and false only, which is the schema this tool uses, so NO stays a string here. The mismatch matters because many YAML libraries still default to 1.1 behaviour, so the same file can parse differently in your CI pipeline than it does here. Quoting the value is the only portable fix.
What happens to comments when I convert YAML to JSON?
They are discarded, permanently. JSON has no comment syntax, so there is nowhere to put them. This makes YAML to JSON a lossy transform for any file whose comments carry meaning, which for configuration files is most of them. Converting back to YAML afterwards produces a structurally correct file with all the explanatory text gone, so never treat a round trip through JSON as a safe way to reformat a commented YAML file.
How are anchors and aliases handled?
They are expanded. An anchor (&name) marks a node and an alias (*name) refers back to it, and merge keys (<<: *name) splice a mapping's contents into another. JSON has no equivalent, so every reference is replaced by a full copy of the value. A file that used one anchor in ten places becomes ten independent copies, which is correct but larger, and any intent to keep those values in sync is lost.
Why did version 1.10 become 1.1?
Because unquoted 1.10 is a number, and trailing zeros are not significant in numbers. Version strings, semantic version fragments, and anything else where the literal text matters must be quoted. The same class of bug hits sexagesimal-looking values in older YAML 1.1 parsers, where 12:30 could be read as base-60 and become 750. If a value's exact characters matter, quote it.
Is every JSON file also valid YAML?
Under YAML 1.2, yes, by design: the specification made JSON a strict subset, so a valid JSON document is a valid YAML document. The reverse is emphatically not true, since YAML adds comments, anchors, multiple documents per stream, unquoted scalars, and several block styles that JSON cannot express. That asymmetry is why JSON to YAML always succeeds while YAML to JSON can lose information.