Converters

YAML to JSON

Turn a single YAML document into JSON, with limits on what carries over.

Reverse
Input
YAML input
Output
Result
Options

Spaces per level of nesting.

Further reading

  • How to convert YAML to JSONConvert YAML to JSON with the actual parser rules: YAML 1.2 defaults, configured merge expansion, duplicate and multi-document rejection, and directives.

About this tool

YAML has features that JSON cannot represent directly. This converter accepts one document, discards comments without a dedicated result warning and expands supported aliases and merge keys. Multi-document streams are rejected. Duplicate-key checks reject repeated plain string keys such as a:, but do not detect every equivalent YAML key. Result warnings are heuristic, not a complete or always accurate account of changes; custom tag semantics are not guaranteed to survive.

The common use case is feeding a YAML config to something that only speaks JSON: an API request body, a tool with a --json flag, or a JavaScript application that imports configuration at build time.

How to use it

  1. Paste or upload YAMLDrop a .yaml or .yml file, or paste the text.
  2. ConvertPress Convert to JSON, or use Ctrl+Enter.
  3. Read any warningsCheck warnings and compare the output with your source. Warnings can miss changes or flag ordinary text; comments disappear without a dedicated warning. Error locations are shown when the parser supplies them.
  4. Copy or downloadCopy the JSON or save it as a .json file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

Typical config file

Input

# database settings
host: localhost
port: 5432
replicas:
  - db-1
  - db-2
ssl: true
timeout: null

Output

{
  "host": "localhost",
  "port": 5432,
  "replicas": [
    "db-1",
    "db-2"
  ],
  "ssl": true,
  "timeout": null
}

The comment is gone, JSON cannot hold it. Everything else maps directly.

Anchors expanded into copies

Input

defaults: &defaults
  retries: 3
  timeout: 30
staging:
  <<: *defaults
  host: staging.example.com

Output

{
  "defaults": {
    "retries": 3,
    "timeout": 30
  },
  "staging": {
    "retries": 3,
    "timeout": 30,
    "host": "staging.example.com"
  }
}

The merge key is resolved, so the shared values appear in full under staging.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Comments are discarded
JSON has no comment syntax, so YAML comments are discarded without a dedicated result warning. A # inside a quoted string is still data, not a comment. Keep the YAML as your source of truth if its documentation matters.
Anchors and aliases are expanded inline
YAML lets you define a block with &name and reuse it with *name, including merge keys (<<). Supported aliases are expanded into JSON values, so shared references are no longer visible and output can grow. The parser uses maxAliasCount: 100 to limit alias expansion; this is not a nesting-depth limit or a promise that 100 aliases always succeed. Circular references cannot be serialised as JSON.
Multi-document streams are rejected
A YAML file can hold several documents separated by ---, as Kubernetes manifests often do. This converter rejects such a stream without returning partial JSON. Split it and convert each document separately. A single document may still begin with ---; a heuristic warning can incorrectly say only the first document was converted, for example after a version directive.
Keys become strings
YAML permits non-string mapping keys, but the parser produces JavaScript objects whose keys are strings. A key like 2024: becomes "2024", and complex keys get a textual representation rather than preserving their structure. Distinct keys such as 1 and "1" can collide and overwrite a value. Repeated plain string keys such as a: are rejected, but complex, alias or NaN keys can still collide after conversion. Key warnings are heuristic and can miss conversions or flag already quoted keys.
Implicit typing catches people out
Without a version directive, the parser uses the YAML 1.2 core schema: yes, no, on and off stay strings, while true and false are booleans and 1.0 is a number. An explicit %YAML 1.1 directive enables older typing rules. JavaScript IEEE 754 numbers can round large integers or precise decimals; .inf, -.inf, .nan and numeric overflow become null in JSON, and negative zero becomes 0. Quote values that must remain exact text.

Limitations

  • YAML comments are discarded without a dedicated result warning. Warnings are not a complete or always accurate loss report.
  • Multi-document streams are rejected; split the source and convert each document separately.
  • Supported aliases expand into copies within the parser limit. Shared references are lost, and circular structures cannot become JSON.
  • Non-string keys become strings and can collide. Duplicate-key checks do not catch every equivalent YAML key; numeric precision may be lost and non-finite numbers become null.
  • Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

Why did my comments disappear?
JSON has no comment syntax, so comments are dropped without a dedicated result warning. If they matter, keep the YAML file as the source and treat the JSON as generated output.
Why is my multi-document Kubernetes manifest rejected?
A manifest can contain several documents separated by ---. This converter parses one document and rejects a multi-document stream, rather than returning only its first document. Split the file and convert each document separately.
Why did "yes" stay a string instead of becoming true?
The default YAML 1.2 core schema leaves yes, no, on and off as strings. An explicit %YAML 1.1 directive changes the schema and can make those values booleans. Write true or false for booleans, and quote values that must remain strings.
What happens with a very large anchor tree?
The parser limits alias expansion with maxAliasCount: 100 and rejects inputs that exceed its expansion accounting. Even repeated shallow aliases can reach the limit; it is not just a depth check. These errors may have no line or column. The limit is a safeguard, not a guarantee that every large document is safe to process.

Related tools

More YAML tools