Nifty Tools

YAML to JSON

Convert yaml to json in your browser. eemeli/yaml parser handles anchors, aliases, multi-document files, and timestamps. No upload.

Processing mode: Local Browser-local

Waiting for YAML.

How to use it

YAML to JSON Converter — Free, In Your Browser

  1. Paste YAML into the editor or load a `.yaml` / `.yml` file (up to ~10 MB per run). Pick the YAML version (1.2 is the modern default), the multi-document mode, and the indent.
  2. Click Convert. The parser materialises every document, resolves anchors and aliases, normalises timestamps, and returns the JSON-ready value tree.
  3. Copy the JSON to the clipboard or download it as a `.json` file. Nothing leaves your browser.

Good for

Common use cases

People convert YAML to JSON when the source is a config file and the destination is code. YAML is what Kubernetes manifests, GitHub Actions workflows, GitLab CI pipelines, Docker Compose files, Ansible playbooks, Helm chart values, and most CNCF-adjacent tooling write to disk — it's the format that humans can edit by hand because indentation and comments survive. JSON is what most APIs, debug payloads, log lines, JavaScript test fixtures, and dashboard inspectors expect. The conversion is awkward to do in a terminal because the shell tools that look obvious (`yq`, a one-liner in Python with `pyyaml`, a quick `node -e`) all force a context switch and require you to remember which version of the parser you've installed and whether it understands YAML 1.1 versus 1.2. The honest version of this conversion has to handle several real-world YAML features that simpler online converters silently mangle — anchors and aliases (`&id` to declare a reusable node, `*id` to reference it; the materialised JSON should contain the resolved value, not the alias name), multi-document files (a single `.yaml` file can contain many documents separated by `---` lines, common in Kubernetes manifests that bundle a Deployment plus a Service plus an Ingress), YAML 1.1 timestamp literals that need to round-trip as ISO 8601 strings, the well-known difference between YAML 1.1 (where `yes`/`no`/`on`/`off` parse as booleans, the so-called Norway problem) and YAML 1.2 (where only `true`/`false` are booleans), and the indentation rules that distinguish a block-style mapping from a flow-style one. The parser here is the vendored eemeli/yaml library — a JavaScript YAML 1.1 + 1.2 parser used in production by countless tools — and the conversion stays in your browser, so Kubernetes secrets, internal hostnames, and other config-file material never reach a third-party server.

Processing mode

Browser-local

Files are processed by your browser. They never reach our servers.

Questions

YAML to JSON Converter — Free, In Your Browser FAQ

Why use a real YAML parser instead of a regex or simple line-based converter?

Because YAML is significantly more complex than CSV, JSON, or XML and the edge cases bite quickly. Indentation defines structure (with rules about consistent space-only indentation versus tabs), anchors and aliases let one node reference another, multi-document files are normal, flow-style and block-style can be mixed, scalars can be plain, single-quoted, double-quoted, literal (`|`), or folded (`>`), comments need to be ignored safely during parsing (JSON has no comment syntax, so they are dropped from the output), and YAML 1.1 versus 1.2 disagree about the meaning of unquoted `yes`/`no`/`on`/`off` (the so-called Norway problem, where the unquoted ISO country code `NO` parses as boolean `false` under YAML 1.1). A regex or line-based shortcut gets the easy cases right and silently produces wrong output on the harder ones — which for a config-file consumer is exactly the wrong failure mode. The parser used here is the vendored eemeli/yaml library, which implements both YAML 1.1 and 1.2 properly.

How are anchors and aliases handled?

Anchors (`&id` next to a node) declare a reusable value. Aliases (`*id`) reference it. The parser resolves every alias to the value its anchor declares before producing the JS tree, so the JSON output shows the materialised value in every position the alias appeared. Chained aliases (one anchor referenced from multiple sites, including aliases inside flow-style mappings) all expand correctly. The one case that cannot round-trip is a cyclic anchor — `&a [*a]` declares an array that contains itself — because JSON has no way to encode a cycle without breaking referential integrity. Cyclic structures surface as a clear error rather than producing a string of nested `[Object]` placeholders or a stack overflow. One related feature behaves by YAML version and is worth knowing about: the merge key `<<: *defaults`. Under YAML 1.1 it is the documented mechanism for "merge the keys of the referenced mapping into this one," and the parser flattens the merged keys into the host mapping before serialising — the JSON output contains the merged result with no surviving `<<` key. Under YAML 1.2 (the modern default), merge keys are not part of the spec and the parser keeps `<<` as a literal mapping key whose value is the referenced mapping. Pick YAML 1.1 when the source file uses `<<:` to compose configuration (older Rails, Ansible, GitLab CI templates often do) and YAML 1.2 when the source treats `<<:` as a normal key.

What does the multi-document mode setting do?

A single YAML file can contain multiple documents separated by `---` lines — common in Kubernetes manifests that bundle a Deployment, a Service, and an Ingress in one file. The default "Auto" mode returns a single JSON value when the file has one document and a JSON array of documents when it has more than one. "Always array" wraps the output in an array even for single-document input, which is useful when the destination consumer always expects a list. "First document only" returns the head document and ignores the rest, which is useful for a quick inspection of the lead manifest in a long file.

What's the difference between the YAML 1.2 and 1.1 options?

YAML 1.2 (the default here) is the modern spec — booleans are only `true` and `false`, numbers parse by JSON-like rules, and the Norway problem (where `NO` parsed as `false`) is gone. YAML 1.1 also treats `yes`, `no`, `on`, `off`, `y`, and `n` as booleans, supports sexagesimal numeric literals (`1:20:30` parsing as the integer 4830), and is what older tools (pre-2009 YAML files, some Ansible installations, legacy Ruby-on-Rails configs) emit. Pick 1.2 for current Kubernetes, GitHub Actions, and Docker Compose files; pick 1.1 only when the source is known to predate the 1.2 spec or when an `NO` in the input should mean `false` rather than the string `"NO"`.

How are YAML timestamps converted?

YAML 1.1 includes a timestamp literal — `2024-04-27T10:30:00Z` parses as a date value rather than a string. The parser normalises every timestamp to its ISO 8601 string form before serialising, so the JSON output contains a quoted ISO string rather than a non-portable Date object. One JavaScript-side caveat is worth being honest about: timestamp values whose components are out of range (a month past 12, a day past 31) get rolled forward by the JS Date constructor — `2024-99-99` becomes `2032-06-07T00:00:00.000Z` rather than an error. The wrapper rejects the cases the parser surfaces as Invalid Date, but it cannot retroactively distinguish a deliberate-but-rolled date from a typo. Treat the ISO string in the JSON output as the canonical interpretation of whatever the source meant.

What happens when the YAML is malformed or contains an unresolved alias?

Both surface as a clear error with the line and column position from the parser. Indentation errors, unbalanced flow-style brackets, an alias that references an anchor that was never declared, and an unclosed string scalar each produce a single error message rather than partial output. The page does not promise that every YAML file in the wild parses — it promises that when the parser stops, the message tells you where to look. Note that an unquoted sexagesimal token like `1:20:30` does not error in either YAML 1.2 (where it parses as the plain string `"1:20:30"`) or YAML 1.1 (where it parses as the integer `4830`); pick the YAML version that matches the source file's expectations.

Is there a file size limit for YAML to JSON?

Each run stays under roughly 10 MB. The parser materialises the full document tree in memory before serialising to JSON, so very large bundles (thousands of generated Kubernetes manifests in one file, for instance) can stall on lower-RAM devices. If your YAML is larger, split it on `---` document separators, convert each chunk, and concatenate the resulting JSON arrays. For multi-megabyte production manifests the right tool is usually `yq -o=json` or a streaming parser in Node — this tool is built for the everyday "paste a manifest into a debug payload" case.

Will this tool stay free?

The basic workflow is designed to stay free. Paid upgrades later will focus on bigger limits, batch work, OCR, saved presets, and ad-free use.