YAML to JSON Converter
Convert one or more YAML documents to JSON with YAML 1.2 core scalar rules, while keeping aliases, mapping-key limits, and conversion loss visible.
Multi-document streams separated with --- are supported.
0 lines
JSON output
YAML data is resolved before JSON serialization.
Converted JSON will appear here.
YAML Has More Ways to Express Data Than JSON Can Carry
JSON gives you objects with string names, arrays, strings, finite numbers, booleans, and null. YAML adds a richer representation model plus features such as anchors, aliases, tags, directives, multiple documents, and multiple scalar styles. The YAML 1.2.2 specification separates the representation graph from presentation details such as comments, scalar style, directives, and anchor names.
Conversion is therefore not merely replacing indentation with braces. YAML is resolved into JavaScript data first, then checked for values and graph relationships that ordinary JSON cannot carry before serialization begins.
Predictable scalar types over ecosystem guessing
YAML 1.2 core scalar rules are used deliberately. An unquoted date such as 2026-09-01 remains text rather than becoming a JavaScript Date, while ordinary YAML 1.2 booleans, numbers and null values keep their scalar types. Application-specific tags are not guessed during conversion.
Multiple YAML Documents Need a New Container in JSON
YAML is a stream format and can contain several documents separated by ---. JSON has no equivalent stream syntax inside one JSON text: it has one top-level value.
When the input contains several YAML documents, the JSON result is one array with one element per document. That is an intentional transformation, not something implied by the original YAML hierarchy. An empty YAML document is represented as null rather than disappearing from that array.
Anchors and Aliases Show Where “Equivalent Values” Are Not the Whole Story
defaults: &defaults retries: 3 enabled: true service: settings: *defaults
YAML can express graph relationships through anchors and aliases. After loading, JSON can contain the repeated resolved values, but it cannot record the anchor name or say that two locations originated from the same alias relationship. A circular alias graph cannot be serialized by ordinary JSON.stringify() at all.
Alias expansion also has a resource cost: a small YAML source can describe a much larger resolved structure. Before serialization, the resolved graph is walked with depth and expanded-value limits so a pasted alias pattern cannot grow without bound in the browser.
Mapping Keys Are a Hidden Compatibility Boundary
JSON object names are strings. YAML mappings can use scalar keys with other resolved types and can even express complex keys. A YAML key such as 1: may end up represented as the JSON object name "1", which loses the original key type. A complex sequence or mapping key has no faithful JSON object-key equivalent.
Several obvious key-risk patterns are flagged before output, but YAML is expressive enough that a source-text check cannot prove every key conversion is lossless. If key identity matters, inspect the generated JSON rather than treating successful serialization as equivalence.
Comments and Human Formatting Disappear by Design
YAML comments often explain why a value exists, record deployment caveats, or guide the next person editing a configuration file. JSON data has no comment member, so those notes disappear in a normal data conversion. Folded versus literal block styles, explicit quoting, flow-style collections, directives, and document markers disappear for the same reason: they describe YAML presentation rather than JSON data members.
If you need a round trip that preserves comments and formatting, use an AST/CST-aware YAML editor rather than a value converter.
The << Merge Key Is Not a Safe Assumption Across YAML Consumers
The familiar <<: merge-key feature comes from YAML 1.1-era type conventions and is not part of the YAML 1.2 core schema used here. Merge-key-looking syntax is surfaced instead of pretending that inheritance has definitely been applied.
If the source belongs to Docker Compose, CI tooling, a framework, or another product with its own YAML loader, validate how that product resolves merges before comparing its runtime configuration with this generic JSON output.
A Successful Conversion Does Not Validate the Original Configuration
Converting a Kubernetes manifest or application config into JSON proves only that the YAML values resolved under these rules can become JSON. It does not prove that required fields exist, API versions are current, environment variables are valid, or the destination application accepts the structure.
Use the generated JSON when another API or tool requires JSON; use the application's own validator when you need configuration correctness. RFC 8259 is the boundary on the JSON side: one JSON text carries one serialized value, object names are strings, and non-finite numbers are outside the JSON number grammar.