Convert YAML to JSON or JSON to YAML instantly in your browser. Upload a file, see parse errors with line numbers, then copy or download the result.
Paste YAML and get JSON, or flip the mode and paste JSON to get YAML. Conversion happens as you type, entirely in your browser — nothing is uploaded and nothing is stored. You can also load a file directly (.yml, .yaml, .txt, or .json), copy the output to the clipboard, or download it. A Load Sample button drops in a small working document in either direction if you just want to see the shape of the output.
When the input will not parse, the parser’s own error message is shown with the line and column, which is usually enough to find an inconsistent indent or a stray tab. When it does parse, a small summary reports whether the top level is an object or an array and how many keys or items it has — a quick sanity check that you converted the document you meant to.
Almost every configuration format in modern infrastructure is one of these two. Kubernetes manifests, GitHub Actions workflows, Docker Compose files, Ansible playbooks, OpenAPI specifications, and CI pipeline definitions are YAML. APIs, log pipelines, package manifests, and most tooling that speaks over the wire are JSON. Converting between them comes up constantly:
YAML 1.2 is formally a superset of JSON: every valid JSON document is also valid YAML, which is why you can paste JSON into a YAML file and it works. The reverse is not true, and the parts of YAML that JSON lacks are exactly the parts that need care in a conversion:
| Feature | YAML | JSON | What happens on conversion |
|---|---|---|---|
| Comments | # to end of line | None | Silently discarded — the biggest practical loss |
| Anchors and aliases | &name / *name | None | Expanded in place; the shared reference becomes duplicated data |
| Multiple documents | --- separators | One value per document | Rejected — convert one document at a time |
| Multi-line strings | | literal, > folded | Escaped \n | Preserved in meaning, not in style |
| Non-string keys | Allowed | Strings only | Coerced to strings |
| Timestamps | Native type | None | Emitted as an ISO 8601 string |
| Trailing commas | N/A | Illegal | A common cause of JSON parse errors |
Comments are worth dwelling on. If you round-trip a heavily annotated Kubernetes manifest through JSON and back, every explanatory comment is gone and no error is raised. Convert a copy, not the file your team maintains.
Anchors and aliases behave the way most people want but not the way the source document said. Given:
defaults: &defaults
retries: 3
staging:
<<: *defaults
the alias is resolved and the values are written out in full at each use site. The output is correct; it is just no longer DRY, and editing one copy no longer changes the other.
YAML infers types from unquoted scalars, and that inference is where silent data corruption comes from. The parser used here follows the YAML 1.2 core schema, which is stricter than the old 1.1 behaviour but still has sharp edges. Some real results:
| YAML input | JSON output | Note |
|---|---|---|
zip: 02134 | "zip": 2134 | Leading zeros are lost — the classic postcode and account-number bug |
version: 1.20 | "version": 1.2 | Trailing zero gone; a version string became a number |
id: 12345678901234567890 | 12345678901234567000 | Beyond the safe integer range for a double, precision is lost |
count: 1_000 | 1000 | Underscore digit separators are accepted |
date: 2026-08-12 | "2026-08-12T00:00:00.000Z" | Parsed as a timestamp, emitted as ISO 8601 in UTC |
value: ~ | null | ~, null, and an empty value are all null |
The fix in every case is the same: quote it. zip: "02134" stays a string, version: "1.20" stays a string, id: "12345678901234567890" keeps every digit. If a value is an identifier rather than a quantity you intend to do arithmetic on, quote it as a matter of habit.
One historical hazard that does not apply here is worth mentioning because so much advice still warns about it. Under YAML 1.1, unquoted no, yes, on, and off were booleans, which is how the country code for Norway famously became false. The 1.2 core schema recognises only true and false (in any capitalisation), so country: no converts here to the string "no". Other parsers in your pipeline may still use 1.1 rules, so quoting remains the safe habit — but this converter will not do that to you.
Duplicate keys are rejected rather than silently overwritten. x: 1 followed by x: 2 produces a parse error naming the line, which is a feature: in a long manifest, a duplicated key where the second quietly wins is a genuinely hard bug to find by eye.
YAML errors almost always come from one of a handful of causes:
key:value is a single scalar; key: value is a mapping.*, &, @, %, {, [, or a leading - followed by a space — which the parser reads as syntax.JSON errors are narrower and usually one of: a trailing comma before } or ], single quotes instead of double quotes, unquoted keys, a comment (JSON has none), or curly “smart” quotes pasted from a document. The reported position is generally accurate; look just before it.
JSON output uses two-space indentation, which is what most linters and diff tools expect. YAML output uses two-space indentation, folds long lines at 120 characters, and expands aliases rather than emitting anchors. That last choice means the YAML you get back is always self-contained — useful when it is going somewhere that may not resolve references, and something to be aware of if you were relying on the anchor for maintainability.
Long single-line strings are emitted in folded block style (>-) rather than as one very long line. The parsed value is identical; only the presentation differs.
For JSON alone, the JSON formatter and validator handles pretty-printing, minifying, and validating. The CSV to JSON converter covers tabular data. If the YAML in question is a Kubernetes workload definition, the Kubernetes manifest validator checks it against the schema and flags security issues, and the Dockerfile generator produces the image those manifests will run.
No. Parsing and serialisation both run in your browser. Files you select are read locally and never leave the machine, which makes the tool safe for configuration containing internal hostnames or infrastructure detail.
No, and they cannot be — JSON has no comment syntax. They are discarded without warning. Round-tripping an annotated file through JSON and back will strip every comment, so work on a copy.
An unquoted 02134 is parsed as the number 2134. Quote any value that is an identifier rather than a quantity: "02134". The same applies to version strings such as 1.20, which otherwise becomes the number 1.2.
No. Files containing several documents separated by --- produce an error saying a single document was expected. Split them and convert each in turn, or wrap them in a JSON array manually afterwards.
They are resolved and the referenced values are written out in full wherever they were used. The data is correct but no longer shares a single definition.
Not here. This converter follows the YAML 1.2 core schema, in which only true and false are booleans, so no stays the string "no". Older 1.1 parsers elsewhere in your toolchain may still coerce it, so quoting remains a sensible habit.
Conversion fails with an error naming the line, rather than silently keeping the last value. That is intentional — a duplicated key in a long file is a bug worth surfacing.
There is no hard limit, but everything runs on the browser’s main thread, so multi-megabyte documents can make the page pause while parsing. For very large files a command-line tool is a better fit.
The usual suspects are a trailing comma, single quotes instead of double quotes, unquoted keys, or curly quotes pasted from a word processor. The error message gives a position — look immediately before it.
Not currently; both formats are emitted with two-space indentation, which matches the prevailing convention for Kubernetes, GitHub Actions, and most linters. Reindent afterwards if your project uses a different style.
YAML (YAML Ain't Markup Language) and JSON (JavaScript Object Notation) are two of the most popular data serialization formats used in modern software development. While both serve similar purposes, they have distinct characteristics that make them suitable for different use cases.
YAML is a human-friendly data serialization format defined by the official YAML 1.2.2 specification. It uses indentation-based syntax to represent structure, making it exceptionally readable for configuration files, CI/CD pipelines, and infrastructure-as-code templates. YAML supports features like comments, anchors, and aliases that enhance maintainability.
JSON is a lightweight data interchange format standardized by RFC 8259 and ECMA-404. It uses a bracket-and-brace structure that is easy for machines to parse and generate. JSON is the backbone of modern web APIs and is natively supported in virtually all programming languages.
This tool performs bidirectional conversion between YAML and JSON formats entirely in your browser using the industry-standard js-yaml library:
yaml.safe_load()) when processing untrusted input to prevent deserialization attacks.yes, no, on, off are interpreted as booleans—quote them if you need strings.*anchor) reference defined anchors (&anchor).null instead.| Feature | YAML | JSON |
|---|---|---|
| Readability | ⭐⭐⭐⭐⭐ Excellent for humans | ⭐⭐⭐ Good with formatting |
| Parsing Speed | ⭐⭐⭐ Slower due to complexity | ⭐⭐⭐⭐⭐ Fast and consistent |
| Comments | ✅ Supported with # | ❌ Not supported |
| Data Types | Rich (dates, null, custom) | Basic (string, number, boolean, null) |
| File Size | Larger (more whitespace) | Smaller (compact syntax) |
| Use Cases | Config files, IaC, CI/CD | APIs, data exchange, web apps |
Source: AWS - YAML vs JSON Comparison
YAML and JSON are both data serialization formats commonly used in configuration files and APIs. JSON uses braces, brackets, and quotes with a strict syntax, while YAML uses indentation and is more human-readable. YAML supports comments and multi-line strings, making it popular for configuration files like Kubernetes manifests.
Select the YAML to JSON mode, then paste your YAML content into the input panel or upload a .yml or .yaml file. The tool automatically converts your input and displays the JSON output in the right panel. You can then copy the result to your clipboard or download it as a .json file.
The tool supports file uploads up to 10MB in size. This is sufficient for most configuration files and data exports. If your file exceeds this limit, consider splitting it into smaller sections or removing unnecessary data before conversion.
Common errors include inconsistent indentation in YAML (always use spaces, not tabs), missing quotes around special characters, or invalid JSON syntax like single quotes instead of double quotes. The error message will indicate the specific issue. Try the Load Sample button to see correctly formatted examples.
Yes, all conversion processing happens entirely in your browser using JavaScript. Your data is never sent to any server, making it safe to convert configuration files containing sensitive information like API keys or credentials. Clear your browser tab when finished for additional security.
After conversion, a statistics panel displays the data structure type (Object or Array) and details like the number of keys for objects or items for arrays. This helps you quickly verify that your data was parsed correctly before using the output.