YAML to JSON Converter
Convert YAML to JSON format instantly. Paste or upload your YAML file.
Upload a YAML, YML, or TXT file (max 5MB)
Conversion Options
How to Use:
- Paste your YAML content in the left textarea or upload a YAML file
- Click "Convert to JSON" to transform your YAML
- Copy the JSON output or download it as a file
- Use "Format JSON" or "Minify JSON" to adjust the output
Supported YAML Features:
- Key-value pairs
- Nested objects (indentation-based)
- Arrays (- list item syntax)
- Strings, numbers, booleans, and null values
- Comments (# comment)
- Quoted strings (single and double quotes)
- Multi-line strings (| or >)
This Is a Lightweight Hand-Written Parser — Know Its Real Limits
Unlike server-side conversion built on a full spec-compliant library (like js-yaml or PyYAML), this converter is a compact, purpose-built YAML reader running entirely in your browser. It correctly handles the everyday shape of most config files — nested key/value maps, block-style lists with -, quoted strings, booleans, numbers, and null/~ — but it does not implement the full YAML 1.1/1.2 specification, and a few gaps are worth knowing before you feed it something complex.
Most notably: trailing inline comments are not stripped from values. A full-line comment starting with # is correctly skipped, but port: 8080 # default port will convert to "port": "8080 # default port" as a single string value, not the number 8080 with the comment discarded — because the parser only recognizes comments that occupy an entire line by themselves. If your YAML has inline trailing comments, strip them manually before converting, or move them to their own line above the key.
Other Gaps to Watch For
"Strict Mode" is currently a no-op
The checkbox is wired into the parser's constructor but the parsing logic never actually reads or branches on it — checking it doesn't change the conversion behavior. Don't rely on it to catch YAML syntax issues that "loose" parsing would let through.
Block scalars (| and >) aren't actually parsed
True multi-line string indicators from the YAML spec have no special handling in this parser's value logic — a block scalar will not be reassembled into the multi-line string a spec-compliant parser would produce. If your config relies on | or > for embedded multi-line text (common in Kubernetes ConfigMaps and shell script blocks), verify the output carefully — it likely won't come through as expected.
Inline flow collections split naively on commas
Inline arrays ([a, b, c]) and inline objects ({a: 1, b: 2}) are parsed by splitting on literal commas. A comma inside a quoted string value within that inline structure — e.g. {msg: "hello, world"} — will be misread as a field separator rather than part of the string, producing broken output. Prefer YAML's block style (one key per line) over inline flow style when using this tool for anything with commas in string values.
No anchors, aliases, or multi-document files
YAML's &anchor / *alias reuse syntax and multi-document files separated by --- (both real, spec-legal YAML features JSON has no equivalent for) aren't recognized here. This tool expects one plain document with fully written-out (non-aliased) values.
Tabs, Spaces, and Why Indentation Errors Happen
The real YAML specification disallows tab characters for indentation entirely — only spaces are legal. This parser is more forgiving than the spec: it counts each tab as worth 2 spaces of indentation when comparing nesting levels. That's a convenience, not a standard, and it means a file that mixes tabs and spaces inconsistently across sibling lines can still parse "successfully" here while a strict parser would reject it outright — so a clean conversion through this tool is not proof your YAML will be accepted everywhere else. If you're preparing a file for a strict downstream parser (many production YAML libraries are), convert your indentation to consistent spaces before relying on it elsewhere.
Frequently Asked Questions
Why did my number turn into a string with "# comment" attached?
This parser only strips comments that occupy an entire line by themselves — a trailing inline comment after a value on the same line gets included as part of that value's text. Move the comment to its own line, or remove it before converting.
Does "Strict Mode" catch YAML syntax errors?
Not currently — the option is present in the interface but isn't wired into the actual parsing logic yet, so toggling it won't change how forgiving or strict the conversion is.
My multi-line string (using | or >) didn't convert correctly — why?
Block scalar indicators aren't specially handled by this lightweight parser, so multi-line text blocks written with "|" or ">" won't be reassembled the way a full YAML library would. Flatten the value to a single line, or use a more complete YAML toolchain for content relying on block scalars.
An inline list or object with a comma inside a quoted string broke — what happened?
Inline flow-style collections are split on commas without accounting for commas inside quoted strings. Switch to YAML's block style (each item on its own line with "-" or its own key) to avoid this, especially for string values that contain punctuation.
Does successful conversion here mean my YAML is valid everywhere?
Not necessarily. This parser is more lenient than the YAML specification in places (for example, how it treats tabs in indentation), so YAML that converts cleanly here could still be rejected by a stricter, spec-compliant parser elsewhere. Treat a clean conversion as a good sign, not a guarantee.