YAML-JSON Converter

About YAML-JSON Converter

YAML-JSON Converter is a free online tool for converting between YAML (YAML Ain't Markup Language) and JSON (JavaScript Object Notation) formats. Upload files or paste data, customize formatting options, and download converted files—all processed locally in your browser for complete privacy.

Should I use JSON or YAML for my project?

Use JSON for machine-to-machine communication and YAML for human-edited configuration. JSON is strict, fast to parse, and has only one valid spelling for any document, which makes it ideal for APIs, log files, and serialized state. YAML is a strict superset of JSON 1.2 (per the YAML 1.2 spec) that adds comments, multi-line strings without escaping, anchors and aliases to avoid repetition, and a much terser indentation-based syntax — all great for Kubernetes manifests, GitHub Actions workflows, and Ansible playbooks where a human is the primary author. Avoid YAML where security matters with untrusted input (the historic "Billion Laughs" and tag-execution attacks live there) and avoid JSON where you want comments. The official YAML media type registered in RFC 9512 is application/yaml; JSON uses application/json from RFC 8259.

Why does my YAML value "1.23" become a number when I want a string?

This is the most notorious YAML gotcha and it bites every Kubernetes operator at least once. YAML 1.1 auto-detects scalar types from their syntax: 1.23 is a float, 42 is an int, true / yes / on are booleans, null and ~ are nulls. So a version field written as version: 1.10 silently loses the trailing zero and becomes 1.1; a country field with NO becomes the boolean false; and a serial number 0123 becomes the octal integer 83. To force a string, either quote the value (version: "1.10") or use the explicit type tag (version: !!str 1.10). YAML 1.2 narrows the implicit boolean set to just true and false, but most real-world parsers (PyYAML, JS yaml without options, Kubernetes) still default to 1.1 behaviour. Always quote string values that could look numeric, boolean, or null.

How do anchors and aliases work in YAML — and does JSON have an equivalent?

YAML anchors (&name) capture a node and aliases (*name) reuse it, letting you write a value once and reference it elsewhere in the same document. The merge key << also lets you mix-in a mapping. JSON has no equivalent — every value must be written out in full — so when this converter goes from YAML to JSON it must materialise (expand) every alias into a separate copy of the data, which can blow up the size of documents that relied heavily on aliasing. Going the other way, from JSON to YAML, this converter optionally re-introduces anchors for nodes that appear identically multiple times if you enable the "compact identical subtrees" option. Anchors are also the vector for the infamous YAML "Billion Laughs" attack, so most modern YAML libraries cap alias depth and expansion size by default.

What is the difference between YAML 1.1, YAML 1.2, and YAML 1.2.2?

YAML 1.1 (2005) is the version most legacy parsers still implement by default — including PyYAML, snakeyaml, and Ruby's stdlib. It allows the booleans yes/no/on/off/true/false in any casing, accepts octal numbers via leading-zero (0123 = 83), and parses scientific notation aggressively. YAML 1.2 (2009) realigned the spec to be a strict superset of JSON, narrowed booleans to true/false only, removed the leading-zero octal rule (use 0o123 like JSON5), and tightened many edge cases. YAML 1.2.2 (2021) is a clarifying revision of 1.2 with no breaking changes — most JavaScript YAML libraries are 1.2.2 compliant. This converter targets YAML 1.2 by default. If you maintain Ansible playbooks, Kubernetes manifests, or anything generated by a Python tool, expect 1.1 quirks in the wild and quote ambiguous scalars defensively.

Can I include comments when converting YAML to JSON?

Strictly no. RFC 8259 forbids comments in JSON, and any JSON parser worth using will reject them as a syntax error. YAML comments (# anything) are stripped during conversion and disappear entirely from the JSON output. If preserving comments is critical — for example, you generate JSON from a hand-edited YAML config and want the JSON to remain reviewable — write the comments to a separate file, or switch the output format to JSON5 (which permits both // and /* */ comments) or JSONC (JSON with comments, widely used by VS Code config files). Going the other way (JSON to YAML), this converter has no comments to add because the source contains none, but you can paste the resulting YAML into your editor and add documentation comments freely.

How do multi-line strings work and which YAML style should I choose?

YAML offers two block scalar styles for multi-line text. The literal block | preserves every newline exactly — pick it for code snippets, ASCII art, or anything where line breaks are semantic. The folded block > collapses each single newline to a space (treating successive lines as one paragraph) but preserves blank-line separators — pick it for prose. Both styles support chomping indicators: |+ keeps all trailing newlines, |- strips all trailing newlines, and | (no indicator) keeps exactly one trailing newline. JSON has no multi-line syntax — every newline in a value must be encoded as \n — so this converter expands a YAML literal block of three lines into a single JSON string with two \n characters. Watch indentation carefully: the block content's indent is stripped from every line, so misaligned lines produce ragged output.

How do I stream-convert a multi-document YAML file or a huge JSON document?

A YAML file can contain multiple documents separated by --- markers (often used in Kubernetes manifests bundling several resources). This converter loads them all and produces a JSON array of documents on output; the reverse converts a JSON array back into a multi-document YAML stream. For files larger than the browser can comfortably hold (above ~50 MB), use command-line tools: yq (jq for YAML) handles both directions with yq -o=json input.yaml > out.json and yq -P input.json > out.yaml, while large JSON documents stream through jq, ijson (Python), or JSONStream (Node). The official YAML media type per RFC 9512 is application/yaml and the multi-document syntax is part of the YAML 1.2 spec, so most modern parsers handle the stream form natively without any special flag.

Are YAML's flow-style ({key: value, list: [1, 2]}) and block-style equivalent?

Yes, semantically identical, but stylistically very different. Flow style uses JSON-like braces and brackets and fits on one line — handy for short objects inside larger documents. Block style uses indentation only and is the canonical YAML form for everything multi-line. Most tools (Helm, Kustomize, Ansible, GitHub Actions) prefer block style for readability and to keep diffs minimal. This converter lets you choose: on JSON-to-YAML output, pick "prefer block" (the default) or "prefer flow" or "flow only for primitives." One subtle catch: in flow style, strings that contain commas, colons, brackets, or braces must be quoted because those characters are structural; block style is more forgiving. When in doubt, run the YAML through yamllint to catch ambiguous unquoted scalars before they bite you in production.