JSON ↔ YAML Converter
Convert between JSON and YAML using the standard js-yaml library — both directions, configurable indent, safe-by-default.
Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. TOOLGRID measures tool usage, not the content you enter.
Loading tool…
Browser-basedWhat this tool does
In-browser JSON ↔ YAML converter built on js-yaml. Handles Kubernetes manifests, Docker Compose, ESLint configs, GitHub Actions, and more.
Configurable indent (2 or 4 spaces) on both sides. Output JSON is pretty-printed; output YAML uses block style (the readable form) rather than flow style. References (anchors) in YAML are dereferenced into the equivalent JSON value during YAML → JSON conversion since JSON has no native concept of references.
Core-schema mode (default ON for YAML → JSON) restricts parsing to portable scalar types (string, number, boolean, and null) plus arrays and maps. Turning it off uses js-yaml v4's DEFAULT_SCHEMA, which additionally resolves standard YAML constructs such as timestamps, binary values, and merge keys. It does not enable removed JavaScript-specific tags such as !!js/function.
What you can do with this tool
Some Kubernetes operators emit JSON; humans usually edit YAML. Convert between them when copy-pasting examples from docs, switching between tools that prefer different formats, or generating manifests programmatically from JSON-emitting scripts.
Docker Compose YAML is human-friendly but some CI / introspection tools (especially TypeScript-typed ones) prefer JSON input. Convert your compose file once and feed both formats to different parts of your pipeline.
When a YAML config is being parsed incorrectly (wrong types, unexpected nesting, anchor expansion surprises), convert to JSON to see the exact structure your YAML parser is producing. JSON's strict typing reveals what YAML's loose typing hid.
What to check before relying on the result
- Performance and maximum practical input size depend on browser memory, device speed, and the structure of the input.
- Review the generated result before replacing or publishing an original file.
How to use
- 1
Pick the conversion direction (JSON → YAML or YAML → JSON).
- 2
Choose indent width — 2 spaces is conventional for both, 4 sometimes preferred for deeply-nested YAML.
- 3
Paste your input. The output regenerates live; parse errors are surfaced inline so you can fix and re-run.
Use Cases
Some Kubernetes operators emit JSON; humans usually edit YAML. Convert between them when copy-pasting examples from docs, switching between tools that prefer different formats, or generating manifests programmatically from JSON-emitting scripts.
Docker Compose YAML is human-friendly but some CI / introspection tools (especially TypeScript-typed ones) prefer JSON input. Convert your compose file once and feed both formats to different parts of your pipeline.
When a YAML config is being parsed incorrectly (wrong types, unexpected nesting, anchor expansion surprises), convert to JSON to see the exact structure your YAML parser is producing. JSON's strict typing reveals what YAML's loose typing hid.
Some configs are easier to template in JSON (or your template engine outputs JSON). Generate the JSON via your template, then convert to YAML for the final consumer.
Convert JSON → YAML → JSON (or vice versa) and diff against the original with our JSON Diff Checker. Differences can reveal type coercion, numeric representation changes, and YAML-only structures that do not survive the conversion.
Tips & Tricks
In YAML 1.1 (which many parsers still default to), values like <code>yes</code>, <code>no</code>, <code>on</code>, <code>off</code>, <code>Y</code>, <code>N</code> are booleans. The Norway problem (country code <code>NO</code> in unquoted form becoming <code>false</code>) bit many people. YAML 1.2 fixed this but old parsers persist. If your input has such values, quote them explicitly to keep them as strings.
JSON is brace-delimited so indentation is decoration. YAML uses indentation as structure — change indent and you change meaning. Convert JSON → YAML with the indent your target system expects, especially when piping into systems with strict format requirements (Helm, Ansible).
Custom YAML tags like <code>!!js/function</code> or <code>!!js/regexp</code> allow code execution during parsing — extremely dangerous with untrusted input. Safe mode (CORE_SCHEMA) rejects these. Only disable safe mode when you control the input and have a specific reason.
YAML anchors (<code>&name</code> / <code>*name</code>) are dereferenced into copies during conversion, because JSON has no equivalent. If your YAML relies on anchor sharing (e.g., two keys both pointing to the same object), the JSON output has two independent copies. Most uses don't care, but be aware if you're processing the JSON further.
FAQ
What YAML version is supported?
The js-yaml library supports YAML 1.2 with the CORE_SCHEMA by default in safe mode. Most modern YAML you'll encounter (Kubernetes manifests, Compose files, GitHub Actions, ESLint configs) conforms to YAML 1.2 and parses cleanly.
Does the conversion run entirely in my browser?
js-yaml is a pure-JavaScript library shipped as part of the page. Conversion runs in your browser, and tool code does not submit entered YAML or JSON to a TOOLGRID processing endpoint. Review browser extensions and device security before handling sensitive configuration.
Why does my YAML fail to parse?
Most common causes: (1) inconsistent indentation (tabs vs spaces, or different space widths), (2) missing colons after keys, (3) unquoted strings that the parser interprets as booleans (yes/no/on/off — the Norway problem), (4) custom !!type tags that safe mode rejects. The error message points at the line; fix incrementally.
Does YAML support things JSON doesn't?
Yes. YAML has comments (#), multi-line strings (>, |), anchors and aliases (&, *), and explicit tags (!!). JSON has none of these. When converting YAML → JSON, comments are dropped, multi-line strings are collapsed to single strings (preserving line breaks via \n), anchors are dereferenced, and custom tags either parse to their underlying type or fail in safe mode.
What happens to YAML comments during conversion?
They're dropped. JSON has no native comment syntax (despite many parsers permissively allowing them). If you need to preserve comments through a round-trip, use a comment-aware library like js-yaml's full schema mode with manual handling — but most workflows accept comment loss as a known trade-off.
Can I convert a YAML file with multiple documents?
js-yaml supports multi-document YAML (separated by <code>---</code>), but the tool currently loads only the first document. For multi-document files, split them on <code>---</code> first and convert each separately.
Is the converter lossless for round-trips?
Ordinary JSON object, array, string, boolean, and null semantics generally survive JSON → YAML → JSON, but the conversion is not guaranteed lossless. Numeric edge cases such as large integers, negative zero, or representation changes can differ after parsing and serialization. YAML → JSON → YAML also drops or expands YAML-only features such as comments, anchors, scalar styles, and explicit tags.
Useful next steps
Open a nearby browser tool when you need to validate, convert, or reuse the result.