Paste any YAML document and get clean, formatted JSON instantly. Supports nested objects, arrays, multi-line strings, and YAML anchors. No login, no data upload.
YAML and JSON share the same data model — objects, arrays, strings, numbers, booleans, nulls — so conversion is lossless in most cases. YAML mappings become JSON objects, sequences become arrays, and scalars become their typed equivalents.
server:
host: localhost
port: 8080
features:
- auth
- logging
{
"server": { "host": "localhost", "port": 8080 },
"features": ["auth", "logging"]
}
Anchors and aliases are resolved before output, so the JSON contains fully expanded values with no YAML-specific references.
YAML has more implicit types than JSON. Most map cleanly, but a few are worth knowing:
| YAML value | JSON output | Notes |
|---|---|---|
42 | 42 | Integer |
3.14 | 3.14 | Float |
true / yes / on | true | Boolean — YAML accepts all three |
false / no / off | false | Boolean |
null / ~ / (empty) | null | Null |
"2024-01-01" | "2024-01-01" | Dates stay as strings in JSON |
!!str 42 | "42" | Explicit type tag forces string |
The common gotcha: bare yes/no/on/off are booleans in YAML 1.1. If you're using them as string values — a port name, a feature flag key — quote them in the source YAML.
K8s manifests and Helm values files are YAML. Converting to JSON lets you query them with JSONPath, validate against a JSON Schema, or pipe values into scripts that expect JSON.
GitHub Actions workflow files are YAML. JSON is easier to parse programmatically when inspecting complex if conditions or matrix configurations.
docker-compose.yml is YAML — converting to JSON makes it straightforward to diff two compose files in the JSON Diff tool. OpenAPI specs are commonly written in YAML; most code generators accept both, but some JSON-only tooling requires conversion first.
Ansible playbooks, ESLint, and Prettier configs all have YAML and JSON variants. Converting is faster than manually reformatting.
| Feature | YAML | JSON |
|---|---|---|
| Comments | Yes — # comment | No |
| Multiline strings | Yes — block scalars ` | and>` |
| Anchors / aliases | Yes | No |
| Human writability | High | Medium |
| Tooling support | Config files, CI/CD | APIs, databases, code |
| Strictness | Loose (implicit types) | Strict |
YAML is for files humans write and read directly — configs, CI pipelines, IaC. JSON is for data machines produce and consume — APIs, SDKs, storage. The two overlap constantly, which is why conversion in either direction is a routine task.
Yes. Anchors (&name) and aliases (*name) are resolved during parsing, so the output JSON contains the fully expanded values with no anchor references remaining.
YAML comments (lines starting with #) are ignored — they have no JSON equivalent and are not included in the output.
Yes. Any valid YAML can be converted, including Kubernetes manifests, Helm values, and Docker Compose files. Multi-document YAML (files with --- separators between documents) will only convert the first document.
In YAML 1.1 (which many tools use), yes/no/on/off are boolean literals, not strings. If you need them as strings, quote them in your YAML source: '"yes"' or '"no"'.
Yes. YAML block scalars (| for literal, > for folded) are parsed correctly and output as a single JSON string. Literal block scalars preserve newlines; folded scalars collapse newlines into spaces.
An error message is shown in the output panel with the line number and description from the js-yaml parser. Common issues are incorrect indentation, missing colons, and unquoted special characters.
No. All conversion happens locally in your browser using js-yaml. Your data never leaves your device — safe to use with Kubernetes secrets, CI tokens, or any sensitive configuration.
More Tools