Convert YAML to JSON Online

How to Convert YAML to JSON Online

1. Paste or Drop Your YAML: Paste YAML into the input panel on the left, or drag and drop a .yaml/.yml file onto the editor. The sample document loads on first visit so you can see the layout immediately.
2. Pick Input as YAML, Output as JSON: Use the format tabs above each panel to set the Input to YAML and the Output to JSON. The arrow between panels (⇄) lets you swap directions if you actually need the reverse.
3. Review and Edit (Optional): The input editor flags indentation errors, tab/space mixing, and malformed scalars before conversion. Fix any underlined lines, or untick Read Only to edit in place.
4. Convert, Copy, or Download: Click Convert. The JSON appears on the right pretty-printed. Use Copy for the clipboard or Download for a .json file. Everything runs in your browser session — no upload, no signup, no watermark.

For the round-trip, see JSON to YAML. To target other formats from the same source, try YAML to XML or YAML to TOML. After conversion, Format JSON handles minify/pretty toggling.

Why Convert YAML to JSON?

YAML is what humans write — Kubernetes manifests, GitHub Actions workflows, Ansible playbooks, Docker Compose files, OpenAPI specs. JSON is what machines and APIs prefer — strict, fast, and parseable by every language on the planet without an extra dependency. Converting between them is a daily reality for anyone working in DevOps, backend, or platform engineering.

• Kubernetes and kubectl — kubectl accepts both YAML and JSON natively (-o json flag, --output=json), but the Kubernetes API server itself speaks JSON. Operators, admission webhooks, and tools like kustomize and Helm all emit YAML that often needs JSON for diffing, jq filtering, or feeding into the API directly.
• API request bodies and Postman — REST and GraphQL endpoints expect JSON payloads. If your fixture data, OpenAPI examples, or environment variables live in YAML for readability, converting to JSON gets you a valid body for curl, Postman, Insomnia, or automated tests without manual reformatting.
• JSON Schema validation — JSON Schema is the de-facto standard for validating structured data. The schema itself can be authored in YAML for comments and readability, but the validator (Ajv, jsonschema, etc.) consumes JSON. Convert before running validation, then ship the JSON to CI.
• jq and command-line pipelines — jq is the indispensable JSON Swiss-army knife but doesn't natively read YAML (you need yq as a sibling tool). Converting to JSON first lets you pipe through jq for filtering, transformation, or building deployment artifacts.
• GitHub Actions and CI artifacts — Workflow files are YAML, but pipeline steps frequently produce JSON outputs (echo "key=value" >> $GITHUB_OUTPUT with JSON values), and downstream actions, webhooks, and Slack/Teams notifications all consume JSON. Converting glue data from YAML to JSON keeps each tool fed in its preferred format.
• Configuration migration — Moving a legacy YAML config into a system that only accepts JSON (some Java apps, AWS service configs, older parsers) is a one-time conversion that's easier to verify when you can diff the round-trip.

YAML to JSON Type Mapping

Most YAML constructs have a clean JSON counterpart, but the implicit-typing rules are where surprises live. The table below shows how the conversion resolves the common cases.

YAML construct	JSON output	Notes
key: value (mapping)	{"key": "value"} (object)	Keys are stringified; JSON requires string keys
- item (sequence)	["item"] (array)	Block and flow sequences both produce arrays
text (plain scalar)	"text" (string)	If it doesn't match a typed pattern
42 / 3.14	42 / 3.14 (number)	Bare numerics become JSON numbers
true / false	true / false (boolean)	YAML 1.2 — see Norway problem below for 1.1
null / ~ / empty	null	Three YAML spellings collapse to one JSON value
2024-05-26 (timestamp)	"2024-05-26" (string)	JSON has no date type; serialized as ISO string
& anchor / *alias	inline duplicated value	Anchors are resolved; JSON has no reference syntax
<<: *base (merge key)	merged object inline	YAML 1.1 merge keys are expanded
--- (multi-doc)	JSON array of docs	JSON allows only one root; docs wrap into [...]
# comment	dropped	JSON has no comment syntax (RFC 8259)
| literal / > folded	string with \n	Block scalars become escaped JSON strings
!!str 42 (tag)	"42" (string)	Explicit tags override implicit types

YAML Quirks That Disappear in JSON

Quirk	What happens in JSON	Why it matters
Comments (#)	Stripped entirely	Capture rationale in a README before converting
Anchors and aliases (&, *)	Expanded inline at every reference	JSON gets larger; semantics identical
Multi-document streams (---)	Wrapped as a JSON array, or last document only depending on parser	Specify which one you want before conversion
Implicit booleans (yes, no, on, off)	YAML 1.1 parsers convert them; YAML 1.2 doesn't	Quote "NO", "on", etc. to stay literal
Complex keys (mapping/sequence keys)	Stringified or rejected	JSON requires string keys per RFC 8259
Custom tags (!Ref, !!python/object)	Tag dropped, underlying scalar kept	App-specific behavior is lost
Trailing newlines and whitespace fidelity	Normalized	Re-emitted YAML won't byte-match the source

Frequently Asked Questions

Multi-document YAML — does the output come out as an array or just the last document?

It depends on the parser. The YAML spec defines a --- separator for multiple documents in one stream, and most modern parsers (js-yaml's loadAll, PyYAML's yaml.safe_load_all) return a list of documents. JSON has no multi-document concept, so the conventional encoding is a JSON array [doc1, doc2, ...]. Some tools instead emit only the last document (yaml.safe_load in Python returns only the final doc). XConvert wraps multi-doc YAML in a JSON array so nothing is silently dropped — if you only need one document, split the file at --- before pasting.

The Norway problem — will country: NO be turned into false?

YAML 1.1 has 22 boolean spellings — y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF — and a parser strictly following 1.1 will turn unquoted NO (Norway) into the boolean false. YAML 1.2 restricted booleans to true|True|TRUE|false|False|FALSE, fixing the bug at the spec level. But popular libraries lag: PyYAML still defaults to 1.1 behavior, and js-yaml v4 switched to 1.2 in 2021. To be safe across parsers, always quote country codes and similar literals: country: "NO". The same trap hits version: 1.10 (parsed as the float 1.1) and surnames like Null.

Will I lose numeric precision on big integers?

JSON itself doesn't bound numeric precision (RFC 8259 only says implementations vary), but in practice every JavaScript-based parser uses IEEE 754 double-precision floats, which preserve integers exactly only up to 2^53 − 1 (Number.MAX_SAFE_INTEGER = 9007199254740991). A YAML value like id: 12345678901234567890 survives as a YAML integer but loses precision in JavaScript's JSON.parse. If you're carrying large IDs (Twitter snowflake IDs, database BIGINTs), quote them in YAML so they convert to JSON strings and don't get silently rounded. Server-side JSON parsers in Python, Go, and Java preserve arbitrary integers when you opt in (json.loads returns native ints; encoding/json with json.Number).

Are JSON5 and JSONC (JSON with comments) supported as output?

No. The output is strict RFC 8259 JSON — no trailing commas, no comments, no unquoted keys. JSON5 and JSONC are non-standard supersets used in editor config files (tsconfig.json, .vscode/settings.json accept JSONC); the only way to "preserve" YAML comments is to add them as keys (e.g., "_comment": "...") before conversion, or stash them in a separate doc file. For sanity-checking the YAML side before conversion, see Validate YAML; for tweaking the JSON output (pretty/minify/indent), use Format JSON.

Anchors &foo and aliases *foo — are they expanded inline?

Yes. JSON has no reference or shared-pointer syntax, so every alias is replaced with a deep copy of the anchored value. A YAML file using a 20-line &defaults block referenced 10 times will produce JSON 10× larger than the YAML. Merge keys (<<: *foo) — which were a YAML 1.1 feature dropped from 1.2 core but still widely supported — are also expanded: the merged map is composed and emitted as a flat object. If your YAML relies heavily on anchors for compactness, expect a sizable JSON growth; that's normal and semantically lossless.

Kubernetes manifests are usually YAML — does kubectl even need JSON?

kubectl apply reads YAML or JSON interchangeably (-f manifest.yaml or -f manifest.json), and the Kubernetes API server itself speaks JSON over HTTPS. So there's no functional reason to convert manifests for kubectl itself. Where conversion helps: piping into jq for filtering, generating diffs with structural awareness, feeding into Helm/Kustomize tooling that prefers JSON, or building admission webhooks that receive AdmissionReview payloads as JSON. Common pattern: author in YAML, convert to JSON at the boundary with a tool like this or yq -o=json.

What about the reverse — JSON to YAML, or YAML to XML?

For the inverse, use JSON to YAML. YAML and JSON are nearly isomorphic for data, so the round-trip is clean except for the YAML features (comments, anchors, multi-doc) noted above. If you're targeting other config formats, YAML to XML and YAML to TOML handle the common cases. For TOML in particular, watch out: TOML's type system is stricter than either YAML or JSON, so heterogeneous arrays may not round-trip.

How does the converter handle YAML timestamps and dates?

JSON has no native date or timestamp type (RFC 8259 only defines string, number, boolean, null, object, array). YAML 1.1 had an explicit !!timestamp type recognizing ISO 8601 patterns; YAML 1.2 dropped it from the core schema but most parsers still recognize the format. The conversion emits dates as ISO 8601 strings — 2024-05-26 becomes "2024-05-26", and 2024-05-26T14:30:00Z becomes "2024-05-26T14:30:00Z". To force a string in the YAML source (and avoid any timezone reinterpretation), quote the value: published: "2024-05-26".

Is my data private?

Yes. The conversion runs entirely in your browser using client-side JavaScript — your YAML never leaves your device, isn't uploaded to a server, and isn't logged. That makes the tool safe for proprietary infrastructure manifests, internal API schemas, and configuration containing tokens or secrets. (You should still rotate any secrets that ended up in source control by accident, regardless of which converter you used.)