YAML ⇄ JSON Converter
Convert config formats, with the counter-intuitive rules made explicit
Input
Result
Mind the YAML type rules: 007 reads as the number 7, yet 08 stays a string; 1e3 is a string while 1e+3 is the number 1000; yes/on become boolean true; 1_000 reads as a number (and y/n are no longer booleans).
Last updated: 2026-10-11
About this tool
YAML is the dominant configuration format, but its type inference rules are strikingly counter-intuitive: 007 parses as the number 7, 1e3 is actually a string, and yes or on become boolean true. These rules come from the YAML 1.1 specification and most parsers follow them — so what you believed was a string reads back as a number, and such problems are time-consuming to track down. This tool surfaces those traps while converting, showing you what your data was actually understood as. It also supports block scalars, anchors and aliases, and multi-document files, and reports an accurate line number when parsing fails.
Features
Follows YAML 1.1 faithfully
007 reads as 7, 0x1f as 31, 1e3 stays a string, yes and on become booleans. These counter-intuitive behaviours match mainstream parsers rather than following invented "reasonable-looking" rules.
Full block scalar support
| preserves line breaks, > folds them into spaces, |- and |+ control trailing newlines, and |2 sets the indent. Clip semantics — whether a trailing newline is added by default — depends on whether the source ended with one, implemented per empirical results.
Anchors and aliases
Both &anchor definitions and *alias references are supported and expanded to their actual content, handy for configs with reused fragments.
Multi-document files
Documents separated by --- become an array with one element per document — nothing is dropped.
Strings survive a round trip
This is the single most important guarantee: a "007" written as a string in JSON must still be a string after conversion to YAML and back. Otherwise one conversion silently corrupts the data.
Errors rather than guesses
Unsupported syntax produces an explicit error with a line number. This tool never papers over uncertainty with a plausible-looking result — wrong JSON is the hardest kind of mistake to notice.
How to use
- 1
Pick a direction
YAML → JSON, or JSON → YAML.
- 2
Paste your config
Paste the configuration content into the input.
- 3
Check the type reading
Verify that numbers, booleans and nulls were understood as you intended.
- 4
Copy the result
Copy the converted output, or download it as a file.
Options
- Direction
- YAML to JSON, or JSON to YAML.
- Indent
- Spaces per level when emitting YAML; 2 by default.
- Flow style
- Whether short arrays use the compact [...] form for readability.
- Line numbers
- Show line numbers on parse failure to help locate the problem in long configs.
Common use cases
- Converting Kubernetes, CI or Docker YAML into JSON to inspect the structure
- Rewriting a JSON config in the more readable YAML form
- Finding out whether a config value was parsed as a string or a number
- Inspecting each document in a multi-document YAML file
- Round-tripping between formats to confirm types are not altered
FAQ
Questions you may have about this tool
Why does 007 become the number 7?
Because YAML 1.1 specifies that a literal beginning with 0 and consisting only of digits is read as an octal or decimal integer. So 007 parses as the number 7, while the prefixed form 0o17 is actually treated as a string by PyYAML. These rules are deeply counter-intuitive but they are the specification, and mainstream parsers follow it. This tool follows the specification rather than inventing "reasonable" behaviour, because once another system reads your config a conforming parser will apply the specification anyway — and the friendlier local reading would have been the misleading one. Quote it as '007' to keep it a string.
Why is 1e3 a string?
Because YAML 1.1 requires a decimal point in scientific notation: only forms like 1.0e3 are parsed as numbers, while 1e3 stays a string. This too is counter-intuitive and was confirmed empirically against PyYAML. The consequence is that writing timeout: 1e3 expecting 1000 can leave some systems holding a string, with unexpected results in comparisons or arithmetic. Writing 1000 directly is the clearest option.
Are yes and no booleans?
Under YAML 1.1, yes. Besides true/false, the pairs yes/no, on/off and y/n all parse as booleans. This is dangerous in configuration: password: no may have been intended as the string "no" but produces boolean false. Quoting any value that could be misread is a sound habit.
What is the difference between | and >?
| is a literal block, preserving line breaks exactly, which suits scripts or code fragments. > is a folded block where adjacent non-empty lines are joined with spaces, with only blank lines producing breaks — suitable for prose paragraphs. Both accept modifiers: |-(strip the trailing newline), |+(keep every trailing newline), and |2 (set the content indent to parent indent plus 2).
Why do tabs cause an error?
Because the YAML specification explicitly forbids tab characters for indentation — only spaces are allowed. It is a historical decision, but every conforming parser rejects documents indented with tabs. This tool names the tab as the cause along with the line number instead of reporting a generic syntax error, because in an editor a tab and a few spaces look nearly identical and the cause is otherwise very hard to find.
What happens with duplicate keys?
An error is raised. The YAML specification requires keys within a mapping to be unique. The common alternative, last-one-wins, lets a single typo silently swallow an entire block of configuration — accidentally writing database: twice would make the whole first section vanish with no warning. This tool reports the problem at conversion time instead.
How are anchors and aliases handled?
&name defines an anchor and *name references it. This tool expands each reference to the actual anchored content, so every location in the JSON output holds the full data — there is no notion of a "reference". That is because JSON has no anchor mechanism, so expansion is the only way to express "these two places hold the same content". The downside is that output can be longer than the input, but it is complete and unambiguous.
Why does some YAML convert to null?
Because it genuinely is an empty document. A file containing only comments, or nothing at all, reads as an empty value per the specification, so a single document with the value null is emitted. Note this differs slightly from PyYAML’s safe_load_all, which returns zero documents for an empty input; from a user’s perspective a YAML file is one document, and reporting "0 documents" is more confusing, so this behaviour is intentionally not followed.