Free YAML to JSON Converter Online

Yes, completely. There’s no sign-up, no account, no usage limit, and no paywall. Every feature on this page is available to everyone, every time.

No. The conversion runs in your browser using JavaScript. Your YAML is never transmitted anywhere — there’s no server-side conversion endpoint, no logging, and no analytics on the content you paste. You can confirm this by opening your browser’s network tab while converting, or by disconnecting from the internet: the page keeps working.

No. It runs in the browser tab you already have open, with no download, no command line tool, and no extension to install. Every online converter has to decide where the conversion actually happens — most send your document to their server, this one keeps it on your machine. If you would rather script the conversion, the guide Convert YAML to JSON in code covers the command line, Python, Node.js, and Go.

There’s no artificial cap. Conversion happens on your own machine, so the practical limit is your device’s memory. Files of a few megabytes convert without trouble; very large documents may briefly pause the page while parsing.

Yes. Use the swap button between the two panes to reverse the direction without leaving the page, or go to the dedicated JSON to YAML converter. Swapping carries the current output across as the new input, so you can round-trip a document.

They’re dropped, because JSON has no syntax for comments. The converter tells you how many were removed rather than discarding them silently. If you need to keep comments, use the YAML Formatter, which reformats YAML in place and preserves them.

Files that separate documents with --- are fully supported. You can output them as a JSON array containing every document, or as JSON Lines (NDJSON) with one compact JSON object per line, which is the format kubectl and most log pipelines expect. Kubernetes manifests and Helm output are typically multi-document.

Yes. Anchors (&name) and aliases (*name) are expanded into their full values, since JSON has no way to express a reference. Merge keys (<<) are resolved by default, which is what Docker Compose, GitLab CI, and Ansible files rely on. You can turn merge resolution off if you want to see the raw << key instead.

YAML 1.2 treats unquoted values like no, yes, on, and off as plain strings. YAML 1.1 treats them as booleans — so country: no becomes false. YAML 1.1 also reads 022 as octal 18 and 12:30 as the base-60 number 750. This converter defaults to YAML 1.2 and warns you whenever a value in your document would be read differently under 1.1.

The two most common causes are a tab character used for indentation, which YAML forbids entirely, and an unquoted value containing a colon, such as title: foo: bar. Unclosed brackets and quotes also surface as indentation errors in most parsers; this converter detects them specifically and points at the delimiter that was never closed.

Yes. If the document can’t be parsed you get a plain-English description of the problem, the exact line and column, a suggested fix, and a marker on the offending line in the editor. The dedicated YAML Validator page is the same engine with the output pane focused on diagnostics.

Yes. yq -o=json input.yaml is the quickest option. In Python, use json.dumps(yaml.safe_load(open("input.yaml"))). In Node.js, use js-yaml. Full examples for Python, Node.js, Go, and the command line are in the guide Convert YAML to JSON in code.

Once it has loaded, yes. Everything needed to convert is already in your browser, so the tool continues to work if you lose your connection.

Paste your YAML into the input pane of the converter at the top of this page — it converts in your browser as you type, so there’s no convert button to press and nothing is uploaded. Set the indentation to 2 spaces, 4 spaces, tabs, or minified, optionally sort the keys, then copy the JSON or download it as a .json file. If the document doesn’t parse you get the exact line and column, a plain-English explanation, and a suggested fix rather than an empty output pane. For a conversion you need to repeat, yq -o=json input.yaml does the same job from a terminal.

Press Upload to pick a .yaml or .yml file, or drag it anywhere onto this page, then press Download to save the result as a .json file. The file is read by your browser and never sent anywhere, which matters for configuration that carries hostnames, registries, or credentials. To convert a YAML file into a JSON file from a shell, use yq -o=json input.yaml > output.json, or convert a whole directory at once with: for f in *.yaml; do yq -o=json "$f" > "${f%.yaml}.json"; done

Yes, in almost every case. YAML 1.2 is defined as a superset of JSON, and any YAML document built from ordinary mappings, sequences, strings, numbers, booleans, and nulls has an exact JSON equivalent. Four things don’t survive the trip: comments, because JSON has no syntax for them; anchors and aliases, which are expanded into their full values since JSON can’t express a reference; mapping keys that aren’t strings, such as dates or nested structures, which JSON doesn’t allow; and custom tags such as !Ref or !GetAtt, which have no meaning outside their own tooling. This converter reports each of those instead of dropping them silently.

It works the other way around: JSON is valid YAML, but YAML is generally not valid JSON. The YAML 1.2 specification defines the language as a superset of JSON, so any JSON document can be handed to a 1.2 parser unchanged — you can paste JSON into the input pane above and it will parse. A YAML document only happens to be valid JSON if it’s written in JSON’s own flow style with every key and string quoted and no comments; ordinary indentation-based documents are rejected by every JSON parser. Note that the guarantee applies to version 1.2 only — 1.1, which PyYAML and older tooling implement, isn’t a strict superset of JSON.

A YAML sequence — the block of lines each beginning with a dash — becomes a JSON array with no extra steps, so ports: followed by - 80 and - 443 converts to "ports": [80, 443]. Two cases surprise people. A document whose top level is a sequence converts to a bare JSON array rather than an object, which is valid JSON and handled here. And a multi-document stream separated by --- isn’t a single array: pick the JSON array output option to wrap every document in one, or JSON Lines to get one compact object per line, which is what kubectl and most log pipelines expect.

JSON is a strict interchange format for machines; YAML is a configuration format for people that can express the same data. Concretely: YAML takes its structure from indentation while JSON uses braces and brackets; it supports comments with # where JSON has none at all; it can reuse blocks through anchors, aliases, and merge keys while JSON repeats every value in full; it can hold several documents in one file separated by ---, where JSON holds exactly one value; and it usually lets you leave strings unquoted, which is convenient until country: NO is read as false. Because YAML 1.2 is a superset of JSON, anything JSON can express, YAML can express too.

Use YAML when a person writes and maintains the file, and JSON when a machine writes or reads it. YAML pays for itself in configuration that gets read in code review — Kubernetes manifests, Docker Compose, GitHub Actions workflows, Ansible playbooks, OpenAPI specifications — because comments can explain the values and anchors keep repetition down. JSON pays for itself in API request and response bodies, log lines, test fixtures, and anything generated or stored at volume: it parses faster, every language ships a parser, there’s no significant whitespace to get wrong, and no version ambiguity to argue about. When both arguments apply, the usual answer is to author in YAML and convert to JSON at build time, which is what the converter at the top of this page is for.

YAML is easier to read and harder to get right; JSON is noisier and far more predictable. On readability YAML wins clearly for nested configuration: no closing brackets, no quotes around every key, no commas to misplace, and comments to explain the values that aren’t obvious — the same Kubernetes manifest is roughly 40% shorter in YAML than in JSON. On usability the trade reverses. Indentation is significant, so a stray tab or a misaligned sibling key breaks the document; unquoted values can silently change type (yes, no, on, off, 022, 12:30); duplicate keys and the split between YAML 1.1 and 1.2 produce files that parse cleanly and still behave wrongly; and YAML parser errors are notoriously vague about where the real problem is. JSON has none of those failure modes, which is why the practical position is to write YAML and validate or convert it before it ships.