Skip to main content
UtilityStack

YAML ↔ JSON Converter — round-trip in your browser

Paste a YAML file and get the JSON. Paste JSON and get the YAML. Switch direction in one click. Runs entirely in your browser using a real YAML parser.

YAML
JSON
{
  "name": "utility-stack",
  "version": "1.0.0",
  "servers": [
    {
      "host": "api.example.com",
      "port": 443,
      "secure": true
    },
    {
      "host": "cdn.example.com",
      "port": 443,
      "secure": true
    }
  ],
  "features": {
    "caching": true,
    "retries": 3
  }
}

Why convert between YAML and JSON?

YAML and JSON are the two dominant configuration formats in modern infrastructure. JSON is the lingua franca of APIs (compact, machine-friendly, supported everywhere); YAML is preferred for human-edited configs (Kubernetes manifests, GitHub Actions, Docker Compose, Ansible playbooks) because it tolerates comments and is less punctuation-heavy.

Conversion between the two is mechanical because YAML is a strict superset of JSON — every JSON document is also valid YAML. The reverse direction can lose information (YAML supports anchors/aliases, multi-line strings and comments that JSON does not), but for most config workloads the round-trip is clean. This tool uses the canonical 'yaml' library, so the parsing matches what your runtime sees.

How to use this tool

  1. Pick the direction you want — YAML → JSON or JSON → YAML — using the toggle at the top.
  2. Paste your source on the left. The converted version appears on the right instantly. Errors are highlighted in red with the parser's exact message.
  3. Use Flip to swap the converted output back into the input — handy for round-tripping or for chaining conversions. Click Copy to grab the result; the indent dropdown adjusts the output formatting.

Frequently asked questions

Is YAML a strict superset of JSON?

Since YAML 1.2 (2009), yes. Any valid JSON document is also valid YAML, with the same structure. That's why pasting a JSON object into a YAML field usually 'just works'. The reverse is not true: YAML has features (anchors, comments, multi-line strings) that JSON cannot represent.

What happens to comments?

JSON has no comment syntax, so when you convert YAML → JSON, all # comments are dropped. The reverse direction (JSON → YAML) cannot magically reintroduce them. If your team relies on comments in config files, keep YAML as the source of truth and treat the JSON as derived.

Are anchors and aliases preserved?

When converting YAML → JSON, anchors are inlined: each &anchor / *alias pair becomes a duplicated subtree in JSON. The other direction can't generate new anchors automatically. If you rely on YAML anchors for DRY configs, keep YAML as your authoring format.

What about long strings?

YAML supports literal block scalars (| keep newlines) and folded block scalars (> fold newlines into spaces). When converting to JSON, both become regular strings with the appropriate newlines or spaces. Going back, the converter picks a sensible YAML representation but may not match your original style.

Are my configs sent to a server?

No. Parsing happens entirely in your browser via the 'yaml' library. Your configs — including any secrets you might have inline — never touch our servers. Safe to use with production manifests.

Common use cases

Where flipping YAML and JSON pays off in seconds.

Kubernetes manifest debugging

kubectl outputs JSON when you run kubectl get -o json; your manifests are usually YAML. Paste the kubectl output into the converter to reformat as YAML for a side-by-side diff with your source manifest.

Programmatically generating configs

Your code emits JSON; your CI/CD pipeline reads YAML. Generate JSON in code, run it through this tool, paste the YAML into your repo. Bonus: indent of 2 matches the convention everywhere.

Reading old config formats

An older system emitted YAML; you're rewriting it in TypeScript and want a typed object. Convert YAML → JSON to get a structure you can import directly with const config = require('./config.json').

Cross-team consistency

Backend uses JSON API specs (OpenAPI in JSON); DevOps uses YAML (helm charts). When the same config concepts span both, this tool keeps everyone aligned without rewriting by hand.

Tips and shortcuts

Habits that prevent YAML/JSON gotchas.

Validate before deploying

If the converter shows red, your YAML is invalid. Don't push it. The error message points at the line and column, which usually maps to a typo (missing colon, bad indentation, mixed tabs/spaces).

Stick to two-space indentation

YAML doesn't care between 2 and 4 spaces, but every linter and formatter expects 2 in the wider ecosystem (Kubernetes, Helm, Ansible, GitHub Actions). Going against it makes your file look strange in code reviews.

Quote strings that look like booleans

Unquoted YAML 'yes', 'no', 'on', 'off' are interpreted as booleans. So 'country: NO' becomes 'country: false'. Always quote string-only values when they look like keywords: 'country: "NO"'.

Beware significant whitespace

Mixing tabs and spaces in YAML is the #1 source of parse errors. Configure your editor to insert spaces (never tabs) when editing YAML files. Most modern editors detect file type and switch automatically.

Herramientas relacionadas