Free JSON to YAML Converter

How It Works

1. Paste JSON: Enter any valid JSON, from flat key-value pairs to deeply nested objects and arrays.
2. Convert instantly: The tool transforms JSON to YAML with proper indentation, removing quotes from string keys and translating null, boolean, and numeric types.
3. Configure output: Set indentation width (2 or 4 spaces) and choose whether to use block or flow style for collections.
4. Copy the YAML: The result is ready to paste into config files, CI/CD pipelines, or Kubernetes manifests.

Why Convert JSON to YAML?

YAML is the preferred configuration format for infrastructure tools like Kubernetes, Docker Compose, GitHub Actions, Ansible, and Helm charts, it's more human-readable than JSON, supports comments, and doesn't require every string to be quoted. Converting API responses, package.json sections, or data structures from JSON to YAML is a frequent task in DevOps and backend development workflows. YAML's indentation-based structure is easier to read for humans, while JSON is preferred for APIs and programmatic generation, this converter bridges the two.

Type Mapping

• Strings → unquoted if safe, quoted if containing special characters
• Numbers → numeric YAML scalars preserved as-is
• Booleans → true / false in YAML
• null → null or ~ in YAML
• Arrays → YAML block sequences with - prefix
• Objects → YAML mappings with key: value pairs

What is JSON to YAML conversion?

JSON to YAML conversion translates a tree of key-value pairs from one serialization format to another while preserving the underlying data. Both formats describe the same shape of data (strings, numbers, booleans, null, arrays, objects), but JSON uses braces and brackets while YAML uses indentation and dashes. The same configuration "name: app, version: 1, ports: 80, 443" can be expressed in either, and converters move between them without losing meaning.

JSON, invented by Douglas Crockford around 2001 and standardized as RFC 4627 in 2006 and ECMA-404 in 2013, is the lingua franca of web APIs. YAML 1.0 (2001), 1.1 (2005) and 1.2 (2009) by Clark Evans, Ingy doet Net, and Oren Ben-Kiki was designed as a superset of JSON optimized for human readability, with support for comments, multi-line strings, anchors and aliases. Modern DevOps tooling (Kubernetes, Docker Compose, GitHub Actions, Ansible, Helm) defaulted to YAML because configs are written and reviewed by humans.

This converter pairs both formats side by side. Paste JSON on the left, click JSON to YAML, and the right pane updates with valid YAML at your chosen indent depth (2 or 4 spaces). The reverse button runs the same process backwards. Conversion uses the js-yaml library (Vitaly Puzrin, 2011) loaded from jsDelivr, which implements the YAML 1.2 spec accurately enough to round-trip Kubernetes manifests, Helm charts, and OpenAPI specs.

What is inside the converter

The interface uses a two-pane grid layout: JSON on the left, YAML on the right. On screens narrower than 768 pixels the layout stacks vertically. Above the panes, an indentation selector lets you pick 2 or 4 spaces per level. The active choice is highlighted, and the indentation applies to both directions of conversion.

Each pane has its own action buttons. The JSON pane offers JSON to YAML (convert) and Clear. The YAML pane offers YAML to JSON (reverse), Copy (clipboard), and Download .yaml (save as a file with .yaml extension and UTF-8 encoding). The error banner below the converter surfaces parse errors with the line number and a short message, so you can fix invalid input without leaving the tool.

Under the hood, the JSON to YAML conversion uses JSON.parse plus js-yaml's dump function. The YAML to JSON direction uses js-yaml's load function plus JSON.stringify with 2-space indent. Both directions are pure functions of the input, no state is carried between conversions, and refreshing the page resets everything.

History and background

Douglas Crockford specifies JSON (2001)

Douglas Crockford documented the JSON syntax in April 2001 while at State Software, after realizing JavaScript's object literal syntax could serve as a language-independent data format. The spec was deliberately minimal: six types, two collections, no comments, no schema. RFC 4627 followed in 2006 and ECMA-404 in 2013. The minimalism is exactly what made JSON ubiquitous on the web.

YAML 1.0 published (2001)

Clark Evans, Ingy doet Net, and Oren Ben-Kiki released YAML 1.0 in May 2001, the same year as JSON. The acronym was originally Yet Another Markup Language but was retconned to YAML Ain't Markup Language to clarify that YAML targets configuration data, not document markup. The 1.0 spec was ambitious, supporting anchors, aliases, multi-document streams, custom tags, and comments.

YAML 1.1 and the Norway problem (2005)

YAML 1.1 (January 2005) tightened the spec but kept the famous boolean-coercion behavior where the strings yes, no, on, off, y, n, true, false, plus their capitalized variants, all become booleans. This is the Norway Problem: the unquoted ISO country code NO becomes the boolean false. The bug bit early Kubernetes users until YAML 1.2 (2009) removed the alternative boolean spellings.

YAML 1.2 declares JSON as a subset (2009)

YAML 1.2 (October 2009) explicitly made JSON a strict subset of YAML, so any valid JSON document is also a valid YAML document. This was a major design win: tools that handled YAML 1.2 could parse JSON for free, simplifying the implementation of converters and validators. The version still in use across most tooling today is 1.2 or a 1.1-compatible profile.

Kubernetes ships YAML manifests (2015)

Kubernetes 1.0, released by Google in July 2015, defined cluster resources (Pods, Deployments, Services) using YAML manifests. The choice was driven by readability for ops teams accustomed to text editors and version control. Helm (2016) added templating on top, GitHub Actions (2018) adopted YAML for workflows, and Ansible playbooks (2012-2018) cemented YAML as the dominant DevOps config language.

js-yaml becomes the de facto JavaScript library (2011 onward)

Vitaly Puzrin published js-yaml in 2011 as a pure-JavaScript port of PyYAML. Subsequent versions (2.0 in 2014, 3.0 in 2015, 4.0 in 2021) tracked the YAML 1.2 spec, added schemas to opt out of dangerous features, and reached over 50 million weekly npm downloads. The library is bundled by webpack, parcel and esbuild for any browser-side YAML work, and is what this converter uses under the hood.

Practical workflows

Authoring Kubernetes manifests

When you generate a Pod or Deployment via kubectl run --dry-run=client -o json, you get JSON. Paste it here, click JSON to YAML, and you have a manifest ready to commit to git. The conversion preserves nested specs, environment variables, and resource limits exactly as Kubernetes will read them.

Docker Compose service definitions

A team-mate sends you a JSON snippet for a new service. Paste it in, convert, and drop the YAML into your docker-compose.yml. The 2-space indent is the Compose default, so leave the indent option at 2.

GitHub Actions workflows

When you scaffold a workflow from a JSON-based template generator or copy a step from a JSON API response, paste it here and convert. The output drops directly into .github/workflows/*.yml. Mind that GitHub Actions also accepts JSON in some fields, but YAML is the canonical form.

Ansible playbooks

Ansible inventories often start life as JSON exported from a CMDB or asset database. Paste, convert to YAML, and you have a hosts file or playbook header that fits Ansible's expected style. Use 2-space indent to match the Ansible community style guide.

Helm chart values

A vendor ships JSON sample configurations for their Helm chart. Convert to YAML and drop into values.yaml. The conversion respects nested keys (image.repository, image.tag, resources.limits.memory) exactly as Helm expects them.

OpenAPI 3 specs

Swagger Editor exports OpenAPI specs as both JSON and YAML. When a tool emits JSON but your team uses YAML in version control (or vice versa), this converter is the fastest way to switch formats without firing up Node, Python, or yq.

Common pitfalls

The Norway problem (yes, no, on, off as booleans)

In YAML 1.1, the strings yes, no, on, off, y, n, true, false (and their capitalized variants) are all booleans. So the unquoted ISO country code NO becomes the boolean false. js-yaml 4.x defaults to YAML 1.2 which only treats true and false as booleans, but older YAML parsers may still trip. Quote ambiguous strings explicitly if you mix tooling versions.

Tabs are not valid YAML indentation

YAML uses spaces, not tabs, for indentation. If your editor inserts tabs by default, the converted YAML will fail to parse in Kubernetes, Helm, or any strict YAML loader. Configure your editor to use 2 or 4 spaces for .yaml and .yml files, or run a linter (yamllint) before committing.

Anchors and aliases do not survive JSON conversion

YAML supports anchors (&name) and aliases (*name) for reusing values. When you convert YAML to JSON, the anchors are expanded inline because JSON has no equivalent feature. The reverse JSON to YAML conversion will not reintroduce anchors automatically. If you need anchors, write them by hand after conversion.

Multi-line strings need explicit indicators

A JSON string with embedded newlines (Hello\nWorld) converts to YAML using the literal block scalar (|) or folded block scalar (>). js-yaml picks the right form, but if you hand-edit the result, remember that | preserves newlines and > folds them into spaces.

Large numbers lose precision

JavaScript numbers are 64-bit IEEE 754 floats, so integers beyond 2 to the 53 (about 9 quadrillion) lose precision when parsed by JSON.parse. The conversion to YAML preserves the lossy value, not the original. If your data has BigInt-style identifiers, encode them as strings in JSON before converting.

Comments are lost in YAML to JSON

YAML supports # comments, JSON does not. When you convert YAML with comments back to JSON, the comments are stripped because JSON has no syntax for them. If you round-trip YAML through JSON for processing, expect to lose every # line. Tools like yq or ruamel.yaml can preserve comments, but the spec-conforming js-yaml drops them.

Privacy and data handling

All conversion runs in your browser via the js-yaml library bundled into the page. We do not send your JSON or YAML to a server, do not log inputs, and do not run analytics on the content of your conversions. The Copy button uses the Clipboard API which requires a user gesture, and the Download .yaml button uses an in-memory blob URL, so the file never round-trips through any network.

Once the page is loaded (including the js-yaml CDN file), the tool works offline. You can disconnect from the network and convert sensitive configuration (API keys, database URLs, internal service names) without any of it leaving your device. The js-yaml file is served from jsDelivr with a Subresource Integrity hash, so the bundle cannot be silently swapped.

When not to use this converter

Streaming megabytes of data

The converter loads the entire input into memory, parses it, and emits the result in one shot. For multi-megabyte JSON or YAML files, use yq or jq in a shell pipeline, or a streaming parser in your favorite language. The browser is not the right tool above 5 to 10 megabytes.

Binary data in JSON

If your JSON has Base64-encoded binary blobs that must be inspected or modified, converting to YAML will not unpack them. YAML supports tagged binary (!!binary) which js-yaml handles, but the bytes remain Base64. Use a dedicated binary editor for actual byte-level work.

Schema validation

This converter checks that the input is valid JSON or YAML, but it does not validate against a schema (JSON Schema, OpenAPI, Kubernetes CRD, Helm values). If you need to know whether a Kubernetes manifest is structurally correct for a 1.28 cluster, run kubectl --dry-run=server or a tool like kubeval, kubeconform.

Schema-aware refactoring

If you need to rename a field across hundreds of YAML files, or upgrade an API version (apps/v1beta1 to apps/v1), use sed, ast-grep, or yq with explicit path queries. The converter only transforms between formats, it does not edit semantic content.

More questions

Is JSON safer than YAML?

For security, yes. PyYAML's yaml.load (before 5.1) and similar permissive parsers could execute arbitrary code from untrusted YAML inputs via tagged Python objects. JSON has no such feature, every JSON parser is safe by design. Modern YAML parsers (PyYAML 5.1+, js-yaml since 4.0) default to safe-load, so the gap has narrowed, but JSON is still the safer default for untrusted input.

Why did YAML choose indentation over braces?

The YAML authors wanted configs to read like outlines, so they used the same convention as Python's significant whitespace. Braces and brackets are valid YAML (flow style), but block style with indentation is the default because it scans more naturally to humans editing in plain text. The trade-off is that whitespace becomes meaningful, which catches editors that auto-trim trailing spaces.

Is YAML always a strict superset of JSON?

Since YAML 1.2 (2009), yes. Any valid JSON document is also a valid YAML 1.2 document. YAML 1.1 had a few edge cases (sexagesimal numbers, the Norway problem) where the relationship was looser. Modern js-yaml uses 1.2 by default, so the superset property holds for this tool.

Why is Kubernetes YAML so verbose?

Kubernetes manifests have a fixed top-level shape (apiVersion, kind, metadata, spec) and the spec contains nested objects mirroring the API's internal Go structs. The verbosity is a side effect of mapping an object-oriented API to a flat-text format. Tools like Kustomize, Helm, and Pulumi reduce the verbosity, but the underlying YAML is what kubectl actually sends to the cluster.

Can I round-trip JSON through YAML without data loss?

For most JSON, yes. Strings, numbers, booleans, null, arrays, objects all survive. Edge cases include very large integers (precision loss), Unicode surrogate pairs (depends on parser), and key ordering (YAML may reorder). If your JSON keys must keep their original order, use a tool that respects insertion order (Python's OrderedDict, json-stable-stringify in JavaScript).

What about TOML and HCL?

TOML (Tom's Obvious Minimal Language, 2013 by Tom Preston-Werner) is used by Cargo (Rust), pyproject.toml (Python), and others. HCL (HashiCorp Configuration Language, 2014) is used by Terraform. Both target the configuration use case but use different syntax. This converter handles JSON and YAML only. For TOML or HCL, use dedicated converters or yq with the right plugin.