JSON to YAML Converter

How to convert JSON to YAML

1. Paste your JSON object or array into the input field.
2. Click "Convert" — the clean, indented YAML output appears instantly.
3. Switch to "YAML → JSON" using the toggle above if you need the reverse direction.
4. Click "Copy" or "Download .yaml" to use the output in your config file, CI/CD pipeline, or Kubernetes manifest.
5. Add YAML comments and anchors manually after conversion if needed — they cannot be inferred from JSON.

How the JSON to YAML converter works

The converter uses js-yaml, running entirely in your browser. When you click Convert, the JSON string is parsed into a JavaScript object with JSON.parse(), then js-yaml's dump() function serializes it to YAML with 2-space indentation. String values that contain special YAML characters or look like other data types are automatically quoted to prevent misinterpretation. No data leaves your machine — the conversion is purely local.

JSON is a strict subset of YAML, so every JSON value has a direct YAML equivalent. The conversion is always lossless in the JSON → YAML direction — all types, values, and structures are preserved exactly. Going back from YAML to JSON may lose YAML-specific features you add manually (comments, anchors, multi-line string style).

// Input JSON:
{
  "name": "my-app",
  "version": "1.0.0",
  "replicas": 3,
  "enabled": true,
  "config": {
    "host": "localhost",
    "port": 8080,
    "tags": ["api", "production"]
  }
}

# Output YAML:
name: my-app
version: 1.0.0
replicas: 3
enabled: true
config:
  host: localhost
  port: 8080
  tags:
    - api
    - production

Who uses JSON to YAML conversion

JSON is common in APIs, package managers, and programmatic code generation. YAML is preferred for configuration files that humans read and edit. Converting JSON to YAML is the standard step when taking API output or generated config into a YAML-native tool.

• DevOps and SRE teams — converting JSON-formatted Kubernetes API responses or Terraform output into YAML manifests for source control.
• CI/CD pipeline authors — transforming JSON-based build configurations into GitHub Actions, GitLab CI, or CircleCI YAML.
• Config file migration — moving a project from JSON config (.eslintrc.json, prettier.json) to YAML (.eslintrc.yaml) for better readability.
• Helm chart development — converting JSON data into YAML values files for Kubernetes Helm charts.
• API documentation — transforming OpenAPI/Swagger JSON specs into YAML format for readability and version control.
• Infrastructure as Code — converting Pulumi or CDK JSON output to YAML for tools that prefer YAML input.

JSON types and their YAML representation

Every JSON type maps directly to a YAML type. The converter uses js-yaml's default serialization, which outputs clean unquoted values where possible and automatically adds quotes when a value could be misinterpreted by a YAML parser.

When to use YAML — and when to keep JSON

Use YAML when:

• Human readability is a priority — YAML eliminates curly braces, square brackets, and double-quoted keys that make JSON hard to scan at a glance.
• Comments are needed — YAML supports # inline comments for documenting config options. JSON has no comment syntax.
• Target tool is YAML-native — Kubernetes, Ansible, Docker Compose, GitHub Actions, and Helm all use YAML as their primary format.
• Repeated values can be extracted — YAML anchors and aliases allow DRY config files where a shared block is defined once and referenced multiple times.
• Multi-line strings appear in the config — YAML's literal (|) and folded (>) block scalars are cleaner than JSON's escaped \n sequences.

Keep JSON when:

• Programmatic generation — code that builds configs at runtime produces JSON more reliably; YAML's indentation-based syntax is fragile to generate via string concatenation.
• API payloads — REST and GraphQL endpoints expect JSON; YAML is not a standard HTTP body format.
• Strict type checking — JSON's quoted strings prevent the ambiguous type coercions that YAML 1.1 introduces for values like NO, ON, and date-like strings.
• Tooling expects JSON — package managers (npm), bundlers (webpack, vite), and many IDE config systems use JSON exclusively.

YAML gotchas: special values and the Norway problem

YAML has several edge cases where an unquoted value is interpreted differently than you might expect. js-yaml handles these automatically when converting JSON to YAML — values that could be misread are quoted in the output. Understanding the rules helps when manually editing the resulting YAML.

• The Norway problem — in YAML 1.1, the bare value NO was parsed as false. This caused the country code "NO" to silently become a boolean. js-yaml uses YAML 1.2 but quotes ambiguous values for compatibility with older parsers.
• Date-like strings — the value 2023-01-01 is parsed as a Date object by some YAML parsers. js-yaml quotes date-like strings in the output to keep them as strings.
• Octal numbers — YAML 1.1 treated values starting with 0 as octal (010 was 8, not 10). YAML 1.2 treats these as integers; js-yaml preserves the correct value.
• Empty values — a YAML key: with no value becomes null in JSON. To produce an empty string, write key: "" in YAML.
• Significant whitespace — indentation is syntactically significant in YAML. The converter always outputs 2-space indentation; mixing tabs and spaces causes a parse error.

// These JSON string values are automatically quoted in the YAML output:
{ "flag":  "true"       }  →  flag:  "true"       // bool without quotes
{ "code":  "NO"         }  →  code:  "NO"         // bool in YAML 1.1 without quotes
{ "date":  "2024-01-15" }  →  date:  "2024-01-15" // Date in some parsers without quotes
{ "num":   "42"         }  →  num:   "42"         // integer without quotes
{ "empty": ""           }  →  empty: ''           // empty string needs quotes

// Unquoted examples (safe values):
{ "name":   "Alice" }  →  name:   Alice
{ "count":  5       }  →  count:  5
{ "active": true    }  →  active: true