YAML ↔ JSON Converter

YAML is the configuration format that won the 2010s by being a strict superset of JSON with more human-friendly syntax. Where JSON requires quotes around every string, brackets around every list, and braces around every object, YAML lets you write configs that look like prose — indentation defines structure, dashes mark list items, colons mark key-value pairs, quotes are optional in most cases. Kubernetes manifests, Docker Compose files, GitHub Actions workflows, Ansible playbooks, OpenAPI specs, Helm charts, and countless application configs all live in YAML, and almost every modern devops workflow involves converting between YAML and JSON at some point in the pipeline. This tool does both directions in a single interface, with the configuration knobs that matter for the cases that actually come up.

The YAML-to-JSON direction is the simpler one and the one most people want. The js-yaml library does the parsing, and we use its JSON-safe schema (yaml.JSON_SCHEMA) rather than the default. The default schema in YAML 1.1 has a quirky tendency to interpret unquoted strings that look like numbers, booleans, or dates as those types — so yes, no, on, off all become booleans, 2024-01-01 becomes a Date object, and the literal string 'NaN' becomes a Number. This is correct per the YAML 1.1 spec but is the source of an entire category of subtle config bugs. The JSON-safe schema treats all unquoted strings as strings unless they are explicitly typed, which matches what most authors actually want. If you really need YAML 1.1's loose typing (you almost never do), you can quote-escape the values that should be typed and use the explicit type tags.

The JSON-to-YAML direction is the cleaner-looking one because the resulting YAML is usually more readable than the JSON source. Strings drop their quotes, brackets disappear, indentation replaces braces, and the result reads like a configuration file rather than a data dump. The js-yaml dump function produces YAML in 'block' style by default (the indented prose-like form most people want), with an option to produce 'flow' style (the JSON-shaped inline form) for cases where you want compactness or programmatic interop. Sort keys is an option worth knowing about: most YAML configs have a conventional key order (apiVersion, kind, metadata for Kubernetes, for example), and sorting alphabetically can break the convention; we leave sort-keys off by default, but enable it for cases where you want deterministic output for diff stability.

Where this tool earns its keep. First, debugging Kubernetes manifests: an error message complaining about a malformed YAML field is easier to triage if you can convert the manifest to JSON and inspect the literal structure. Second, comparing two CI configs (GitHub Actions, GitLab CI, CircleCI all use YAML): convert both to JSON, then diff the JSON for a structural comparison that ignores YAML formatting noise. Third, generating YAML from an existing JSON-shaped data source: many tools and APIs return JSON, but you want to commit a YAML version to a config repo for human readability. Fourth, importing a YAML config into a tool that only accepts JSON (some legacy systems do): one-shot convert and feed it in. Fifth, learning YAML by seeing how a JSON document you already understand maps to the YAML equivalent.

Common YAML pitfalls worth knowing about. The 'Norway problem' is the most famous: NO is parsed as a boolean false in YAML 1.1 default schema (because Norway's two-letter ISO code happens to look like a boolean), so a country list with NO in it surprises everyone. Our JSON_SCHEMA mode avoids this by treating NO as a string, but if you are using a tool that uses default schema (Ruby on Rails before 7.0, some Python tools), keep an eye on it. The 'date problem' is similar: 2024-01-01 unquoted is parsed as a Date in default schema, then serialized as a quoted ISO string when round-tripped — round-trip stability breaks. Quote it explicitly to keep it as a string. The 'tab problem' is YAML's strict no-tabs-for-indentation rule: a single tab in the indentation breaks parsing with a confusing error. Use spaces.

Multi-document YAML (multiple YAML documents in a single file separated by ---) is supported by the parser, but our JSON output produces a single JSON document — for multi-doc inputs, the output is a JSON array where each element is one of the documents. This is a sensible default for most cases. If you need to round-trip a multi-doc file, pre-split it on the --- separators, convert each document independently, and concatenate the JSON outputs. Or use a YAML-specific tool that preserves multi-doc structure across the conversion.

Anchors and aliases (the &name and *name syntax for reusing values) are handled by the parser — the alias is resolved to its anchor's value during parsing, and the JSON output contains the resolved value. This is the right behavior for converting to JSON, but it means the round-trip JSON-to-YAML loses the anchor structure: anchors only exist in YAML, not in JSON, so converting JSON back to YAML produces a YAML document where every place the original used an alias now has a copy of the value. If you need to preserve the anchor structure for round-trip, use a YAML-specific tool. For one-way conversion (the common case), the resolution is what you want.

JSON output formatting offers three modes: 2-space indentation (the most common modern style), 4-space indentation (the long-standing convention in some shops), and minified (a single line, no whitespace, smallest byte count). Each has its place. Use 2-space for most cases where the JSON will be read by humans; use 4-space if your team's codebase already uses that style; use minified when the JSON is going into a transport layer where every byte matters or into a single-line storage column.

YAML output formatting offers a few tweaks. Block style (the default) produces the indented prose-like form. Flow style (alternative) produces the inline JSON-shaped form. Line width controls when long sequences wrap onto multiple lines. The 'no refs' option (default on) prevents the dumper from emitting anchors and aliases (which it would do for repeated nested objects); turning it off gives you compact YAML at the cost of round-trip-only stability. Sort keys produces alphabetically ordered output for deterministic diffs; leave it off to preserve insertion order from the source JSON.

Privacy is the same model as the rest of our tools: nothing is uploaded, nothing is logged, the conversion runs entirely in your browser. The YAML or JSON you paste — including any embedded credentials, internal hostnames, or environment-specific values — never leaves your device. Verify by opening the network tab during conversion. This matters meaningfully for config files, which often contain real secrets or hints about your infrastructure. Many online YAML/JSON converters upload the input to a server, which is often forbidden by corporate policies; this tool does not.

Workflow tips. When converting YAML to JSON for diffing two configs, run both YAML files through the same converter at the same settings, then diff the JSON outputs. Differences between the JSON outputs are real semantic differences; whitespace and quoting differences in the YAML source disappear in the JSON form. When converting JSON to YAML for human review, enable sort-keys so the output is deterministic — the human can scan the output without being confused by arbitrary key ordering. When round-tripping (YAML → JSON → YAML), expect the round-trip to be lossy: comments are stripped (JSON has no comments), anchors and aliases are flattened, and the YAML formatting (block vs flow, line wrap) is regenerated from defaults rather than the original. For lossless round-trip, use a YAML-aware editor.

The tool pairs with the rest of the developer suite. The JSON Viewer handles the JSON side once converted; the JSON to TypeScript generator produces types from the JSON for use in code. The JSON Diff tool is the right place to compare two YAML configs after converting both to JSON. The Schema.org JSON-LD Builder is the related tool for SEO-targeted structured data, which often lives next to YAML configs in front-end repos. The XML ↔ JSON tool is the parallel utility for the XML world. Together with this YAML converter, these cover most of the data-format-juggling that comes up in everyday devops work.