YAML to JSON Converter — Validator & Formatter

YAML to JSON conversion: how it works

This tool uses js-yaml — the most widely-used JavaScript YAML library — to handle the conversion in both directions. When you convert YAML to JSON, the process is: js-yaml parses the YAML text into a JavaScript object tree, then JSON.stringify(tree, null, indent) serializes it to JSON. The conversion is fully in-browser; your data never leaves your machine.

js-yaml implements the YAML 1.2 specification. That matters for edge cases like booleans and octal literals — covered below.

JSON to YAML conversion: the reverse flow

Converting JSON to YAML reverses the pipeline: JSON.parse() reads the JSON string into a JavaScript object, then js-yaml.dump() serializes it to YAML using block style by default. The result is idiomatic, human-readable YAML — nested objects become indented mappings, arrays become block sequences with - prefixes.

One thing that cannot survive the trip: JSON has no concept of anchors, aliases, or comments, so converting JSON to YAML produces clean YAML but with no reuse shortcuts. Round-tripping YAML → JSON → YAML also loses comments and anchor definitions — that is a JSON limitation, not a converter bug.

YAML vs JSON — quick comparison

YAML indentation gotchas

YAML's most common source of parse errors is indentation. The rules:

• Tabs are forbidden. The YAML specification explicitly disallows tab characters for indentation. Every indentation level must use spaces only. Most editors have a "convert tabs to spaces" setting — enable it for .yml and .yaml files.
• Mixing tabs and spaces is a hard parse error. It can be invisible in most editors. If you paste YAML from a source that uses tabs, the converter will report a parse error that looks confusing until you reveal hidden characters.
• Indentation must be consistent within a block. Sibling keys at the same level must be indented by the same number of spaces. Child keys must be indented more than their parent.
• The first level after a block mapping key can use any number of spaces > 0 — typically 2. Whatever you choose, stay consistent throughout the document.

Common YAML types in config files

• Scalars — plain strings, quoted strings, integers, floats, booleans, null. Plain strings do not require quotes unless they contain special characters or could be misread as another type.
• Block mappings — key: value pairs, one per line, indented under their parent key.
• Flow mappings — {a: 1, b: 2} — the JSON-like inline form, valid anywhere a mapping is expected.
• Block sequences — each item on its own line starting with - followed by a space.
• Flow sequences — [a, b, c] — inline array form.
• Block literal strings (|) — preserves every newline. Useful for shell scripts embedded in CI config.
• Block folded strings (>) — folds newlines into spaces, preserving blank-line paragraph breaks. Good for long descriptions.
• Anchors and aliases — &defaults defines a reusable block; *defaults inserts it. <<: *defaults merges a mapping anchor into another mapping.

YAML 1.1 vs YAML 1.2 — what changed

Many tools still implement YAML 1.1 (released 2005). YAML 1.2 (2009) made two breaking changes that catch developers off guard:

• Boolean literals narrowed. In YAML 1.1, yes, no, on, off, true, false, y, n (and their capitalizations) are all booleans. In YAML 1.2, only true and false (lowercase) are boolean. If your Kubernetes or Docker Compose file has enabled: yes and your parser uses 1.2, that becomes the string "yes", not true. This tool uses js-yaml's YAML 1.2 core schema.
• Octal notation changed. YAML 1.1 uses 0777 for octal. YAML 1.2 uses 0o777 (matching Python 3 and other modern languages). File permission values in older configs may parse as decimal integers if you feed them to a 1.2 parser.

Practical examples

A minimal Kubernetes Deployment manifest in YAML, converted to JSON, illustrates how the type system translates. The YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api

Becomes this JSON:

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "api-server",
    "labels": { "app": "api" }
  },
  "spec": {
    "replicas": 3,
    "selector": {
      "matchLabels": { "app": "api" }
    }
  }
}

Notice that replicas: 3 becomes the number 3, not the string "3". YAML's type inference carries through to the JSON output.

When anchors and aliases help — and their JSON limitation

Anchors (&name) and aliases (*name) let you define a value once and reference it multiple times. This is the YAML equivalent of a variable or constant. In a GitHub Actions workflow, a common pattern is to define a &node-defaults anchor with the shared node-version and cache settings, then merge it into every job with <<: *node-defaults.

When you convert YAML with anchors to JSON, the aliases are expanded — each reference becomes a full copy of the anchored value. JSON has no reference mechanism, so the DRY structure is lost. If you convert that JSON back to YAML, you get the expanded form with no anchors. Round-tripping collapses anchors irreversibly.

FAQ

Does round-tripping preserve comments?

No. JSON has no comment syntax, so YAML → JSON conversion discards all # comments. Converting that JSON back to YAML produces valid YAML but with no comments. This is a fundamental JSON limitation. If you need comment-preserving YAML transforms, use a tool that works directly in YAML without a JSON intermediate step.

Why did my number turn into a string after conversion?

Likely a YAML 1.1 vs 1.2 conflict. Values like yes, no, on, off are booleans in YAML 1.1 but plain strings in 1.2 — this tool uses 1.2. Also watch for version numbers like 1.10 being parsed as floats: quote them as "1.10" to preserve the string form.

Is this safe for untrusted YAML input?

Yes. This tool uses js-yaml v4's load() function, which is safe-load by default. It refuses to execute arbitrary JavaScript code via custom YAML tags like !!js/function. The old safeLoad() function from v3 was merged into the default behavior in v4, making unsafe loading opt-in rather than opt-out.

Related tools

• JSON Formatter — Format, validate, and beautify JSON online. 100% client-side — your data never leaves your browser.
• XML Formatter — Format, validate, and beautify XML documents.
• CSV to JSON Converter — Convert CSV files to JSON with proper quoting and escaping.
• JSON Diff — Compare two JSON objects structurally with field-by-field diff.

Related articles

• 5 min readJSON to YAML Conversion — Online Tool and Complete Format GuideConvert JSON to YAML instantly. See syntax differences, understand when YAML is better than JSON, and avoid common conversion mistakes. Free, browser-based tool.
• 5 min readYAML Anchors and Aliases — Reusing Values with & and *YAML anchors (&) define a reusable value; aliases (*) reference it. This eliminates repetition in YAML configuration. Here's how to use anchors, aliases, and merge keys (<<) in...
• 5 min readYAML Config Best Practices — Structure, Validation, and Environment VariablesYAML is the dominant format for configuration files in modern software. Here's how to structure YAML configs, validate them with schemas, handle environment variables, and...
• 6 min readYAML in Kubernetes — Writing Kubernetes ManifestsKubernetes configurations are YAML files called manifests. Here's how Kubernetes YAML is structured, the required fields for common resources (Deployment, Service, ConfigMap),...
• 4 min readYAML Multiline Strings — Literal Block and Folded ScalarsYAML has two multiline string styles: literal block (|) preserves newlines, folded (>) folds newlines into spaces. Here's how to write multiline strings in YAML, control...
• 5 min readYAML Schema Validation — Validate YAML with JSON Schema and AjvYAML doesn't have built-in validation, but you can validate YAML structure using JSON Schema after parsing. Here's how to validate YAML files with JSON Schema, Ajv, pydantic,...

Pillar

Part of Data & Format — JSON, YAML, XML, CSV, SQL, Markdown.

Written by Mian Ali Khalid. Last updated 2026-05-13.