YAML to JSON Converter

Paste a YAML document on the left, read pretty-printed JSON on the right. The parser handles mappings, nested mappings, sequences of scalars, sequences of mappings, quoted strings, numbers, booleans, and null values. Strict indentation handling rejects tabs and mixed indentation with a clear error message rather than silently mis-parsing. Everything runs in your browser: nothing is uploaded, nothing is logged, and the JSON output is canonical RFC 8259 / ECMA-404.

How to use

1. Paste a YAML document into the YAML input textarea on the left.
2. Pick the JSON output indentation (2 spaces or 4 spaces). The default is 2 spaces, which is the standard pretty-print across most editors and pretty-printers.
3. The JSON appears live in the JSON output textarea on the right as you type.
4. If the input contains a syntax problem, an error panel appears under the input area with the line number and a clear description of what went wrong.
5. Click Copy to copy the JSON to your clipboard, Sample to load a representative example, or Clear to wipe both panels.
6. The Validate button toggles strict validation mode: in validate mode, ambiguous scalars are rejected so you catch unintended type coercion early.

What YAML is and when you encounter it

YAML (YAML Ain't Markup Language) is a human-friendly data-serialization format designed to be easy to read and write while remaining parseable by machines. It is whitespace-significant, indentation defines the hierarchy, the way Python uses indentation to define blocks. The most common subset covers three kinds of structure:

• Mappings, key: value pairs, equivalent to JSON objects.
• Sequences, - item lines, equivalent to JSON arrays.
• Scalars, strings, numbers, booleans, and nulls as bare values.

YAML 1.2 is the current specification, and the language deliberately overlaps with JSON: every valid JSON document is also valid YAML. The converter handles the common subset that covers the vast majority of real-world YAML files (Kubernetes manifests, GitHub Actions workflows, Docker Compose, Ansible playbooks, OpenAPI specs). Features outside that subset, block scalars (| and >), anchors and aliases (&name / *name), explicit type tags (!!int), and flow-style collections ({a: 1}, [1, 2]), are rejected with a clear error message so you can refactor them before converting.

The format and the parser

The converter walks the input as a flat list of {indent, content} lines and applies a tiny set of recursive-descent rules:

• Mappings: a key: value line starts a mapping; child keys are indented relative to the parent.
• Sequences: a line starting with - (dash followed by space) starts a sequence item; the dash position defines the sequence's indentation.
• Sequences of mappings: - key: value lines whose child keys are indented one step beyond the dash.
• Scalars: bare strings (no quotes needed), single- or double-quoted strings, integers, floats, scientific notation, booleans (true/false), and nulls (null/~).

The JSON output is JSON.stringify(parsed, null, indent), standard JavaScript, no custom serialisation, no special-cases. The output is canonical: keys appear in insertion order, strings use double quotes, and numbers print with JavaScript's standard formatter. If you need a specific JSON layout (sorted keys, escaped unicode, trailing newline), pipe the output through a downstream tool, the converter stays out of the way.

The conversion formula

The conversion is a single expression over the parsed document:

JSON = JSON.stringify(parseYAML(yamlText), null, indent)

Where parseYAML is the recursive-descent parser described above, yamlText is the raw input, and indent is the chosen output indentation (2 or 4 spaces). The parse step turns the indented YAML lines into a JavaScript object or array; the stringify step renders that structure as canonical ECMA-404 JSON. No conversion is applied between the two steps, so the JSON is a faithful, order-preserving rendering of the YAML the user supplied.

Worked examples

1. Simple mapping. A two-line document like name: Alice / age: 30 becomes {"name":"Alice","age":30}. The bare string Alice is a string because it isn't parseable as a number; the bare integer 30 is a number because it matches the integer regex.

2. Nested mapping. A document like:

person:
  name: Alice
  address:
    city: Paris
    country: France

becomes {"person":{"name":"Alice","address":{"city":"Paris","country":"France"}}}. Notice the indentation: person is at column 0, name is at column 2 (one indent step), address is at column 2, and city / country are at column 4 (two indent steps).

3. Sequence of scalars. A document like:

items:
  - apple
  - banana
  - cherry

becomes {"items":["apple","banana","cherry"]}. Each - line is a sequence item; the indentation of the dash defines the sequence's depth.

4. Sequence of mappings. A document like:

users:
  - name: Alice
    role: admin
  - name: Bob
    role: editor

becomes {"users":[{"name":"Alice","role":"admin"},{"name":"Bob","role":"editor"}]}. The dash position is at column 2, and the name / role keys are at column 4, one step beyond the dash, which the parser uses to recognise them as belonging to the current sequence item.

5. Kubernetes Pod manifest. A minimal Pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      ports:
        - containerPort: 80

becomes a deeply nested JSON document with apiVersion, kind, metadata.name, spec.containers (an array of one object with name, image, and ports), and containerPort: 80. This is the kind of YAML→JSON conversion that matters when you want to send a Kubernetes manifest to a JSON-only API endpoint.

6. GitHub Actions workflow. A workflow file:

name: CI
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm test

becomes a JSON object where on becomes the JSON key (JSON has no other way to express that field), push.branches becomes ["main"], and the steps array becomes an array of objects with uses / with / run keys. YAML's [main] flow-style sequence is supported by the parser and converts to a JSON array.

7. Mixed types and edge cases. A document like:

name: "Alice"     # double-quoted string
nickname: Alice   # bare string (same value, different syntax)
age: 30           # integer
weight: 65.5      # float
active: true      # boolean
deleted: null     # null
empty: ~

shows the type-coercion rules: age: 30 is a number, weight: 65.5 is a number, active: true is a boolean, and deleted: null / empty: ~ are both nulls. The bare Alice and the double-quoted "Alice" end up as the same string value; the difference is only in the source syntax.

8. Deeply nested structure. A document like:

org:
  teams:
    - name: backend
      repos:
        - name: api
          language: go
          services:
            - name: auth
              port: 8080
            - name: payments
              port: 8081
        - name: worker
          language: python
      members: 12
    - name: frontend
      repos:
        - name: web
          language: typescript
      members: 6

becomes a deeply nested JSON object with org.teams[0].repos[0].services[1].port resolving to 8081. The parser tracks indentation through six levels without losing structure, and the JSON output preserves every level in the same order.

9. Empty values and explicit empties. A document like name: (no value), description: "" (empty string), tags: [] (empty sequence), and metadata: {} (empty mapping) all parse cleanly: name becomes null, description becomes "", tags becomes [], and metadata becomes {}. The parser distinguishes between "field missing entirely" (the key isn't in the JSON output) and "field present with empty value" (the key is in the output with null / "" / [] / {}).

10. Numeric edge cases. Scientific notation (1.5e10), negative numbers (-273.15), and zero-padding (007) all convert as expected: 1.5e10 becomes 15000000000 (or 1.5e10 if you request a non-power-of-ten precision), -273.15 becomes -273.15, and 007 becomes 7 (leading zeros are stripped because JavaScript's JSON formatter does not preserve them). To preserve a leading-zero string, quote it: "007".

Where YAML shows up

Kubernetes manifests are YAML by convention: every kubectl apply -f deployment reads a YAML file. Converting a manifest to JSON is useful for hitting the Kubernetes API directly, for diffing manifests, and for storing manifests in JSON-only databases.

Docker Compose files describe multi-container applications in YAML. Converting to JSON is useful when you want to feed a Compose file into a JSON-only configuration system or parse it with a strictly-typed language where the YAML library isn't installed.

GitHub Actions workflows, GitLab CI, CircleCI, and most modern CI systems use YAML as the canonical configuration format. The converter is useful for parsing workflows into structured data without a YAML library, and for sharing workflow snippets with tools that only understand JSON.

Ansible playbooks, Helm values, Prometheus alert rules, OpenAPI specs, serverless framework configs, and most infrastructure-as-code tools default to YAML. JSON conversion is the bridge to any tooling that doesn't speak YAML natively.

Configuration files in general, many modern tools (Traefik, Consul, Grafana, Loki) accept YAML for configuration because it is more compact and more human-friendly than JSON, while still being trivial for machines to parse. If you need to embed a YAML config into a JSON document, this converter does it without losing any data.

Common mistakes

1. Tabs instead of spaces. YAML 1.2 forbids tabs in indentation. The parser rejects tabs with a clear error pointing at the first line that uses one. Always use spaces; 2 spaces per indent is the most common convention.

2. Mixed indentation. Some lines indented with 2 spaces, others with 4 spaces, others with a tab. The parser rejects mixed indentation at the point where the first line uses a different step than its parent. The fix: pick one step (2 spaces is recommended) and apply it consistently across the whole document.

3. Unquoted strings that look like booleans or numbers. A value like yes, no, on, off, true, false is parsed as a boolean, yes and no in YAML 1.1 (the older spec) are booleans, and true/false are unambiguous. A value like 01234 is parsed as an integer, but 01234 is sometimes meant as a phone number or zip code. The fix: quote any value that should stay as a string: "01234" or '01234'.

4. Strings with special characters. A value like Hello: world looks like a mapping because of the colon. The fix: quote the string: "Hello: world" or 'Hello: world'. Same applies to strings that start with -, ?, *, &, !, |, >, ', ", %, @, `, or #, these all have YAML meaning and must be quoted to be treated as literal characters.

5. Anchors and aliases. YAML lets you define a value once with &name and reuse it with *name:

defaults: &defaults
  retries: 3
  timeout: 30
prod:
  <<: *defaults
  host: prod.example.com

The minimal parser does not support anchors/aliases; trying to convert such a document produces an explicit error. The fix: manually inline the values, or use a YAML library that supports the full spec server-side.

6. Block scalars. YAML lets you write multi-line strings with | (literal, preserves newlines) or > (folded, joins lines with spaces):

description: |
  This is a
  multi-line
  description.

The minimal parser does not support block scalars; trying to convert such a document produces an explicit error. The fix: replace | / > with an explicitly quoted multi-line string ("...\n..."), or use a full YAML parser.

7. Trailing whitespace and inconsistent dash positions. A sequence like - apple\n- banana is fine, but -apple (no space after the dash) is a syntax error. The parser rejects it; the fix is to add the space after the dash.

Frequently Asked Questions

Q: Does this converter handle YAML 1.2 multi-document files (separated by ---)? A: No. The converter parses a single YAML document. If your input contains multiple ----separated documents, you must split them yourself (most YAML libraries expose a loadAll function that yields one document at a time) and convert each one separately.

Q: Can it convert back the other way (JSON to YAML)? A: No, this tool is one-way: YAML in, JSON out. For JSON → YAML conversion, use a JSON formatter that emits YAML, or pipe the JSON through a js-yaml-style library that supports both directions.

Q: Why does my YAML yes or no come out as a JSON boolean instead of a string? A: YAML 1.1 (the older spec, still widely supported) treats yes/no/on/off as booleans. YAML 1.2 (the current spec, which the parser follows) only treats true/false as booleans. If you need yes/no as strings, quote them: "yes" and "no".

Q: Why does the parser reject my YAML when it parses fine elsewhere? A: The parser is intentionally a minimal subset. It handles mappings, sequences, scalars, and common indentation, but rejects block scalars, anchors/aliases, flow-style collections, explicit type tags, and several other advanced features. If you need full YAML 1.2 support, use a library like js-yaml (Node.js), PyYAML (Python), or snakeyaml (Java).

Q: Does the order of keys in the JSON output match the order of keys in the YAML input? A: Yes. YAML mappings preserve insertion order, the parser preserves insertion order, and JSON.stringify preserves insertion order. The output JSON has keys in exactly the same order as the input YAML.

Q: How does the converter handle comments? A: Lines starting with # (after any whitespace) are treated as comments and ignored. Inline comments (a # after a value on the same line) are not supported, the parser stops at the # and treats the rest of the line as a comment, but if the # appears inside a quoted string, it is preserved as literal text. The JSON output never contains comments (JSON has no comment syntax).

Q: Can the YAML to JSON Converter be used for professional or commercial purposes?l purposes? A: Yes, the converter provides a correct YAML→JSON translation that is suitable for professional, commercial, and educational use. For high-stakes applications (production infrastructure, regulated workflows), verify the output against a full-spec YAML parser before relying on it. The supported subset covers the vast majority of real-world YAML files, but a small number of advanced features require a full-spec parser.

Q: How often are the underlying parser rules updated? A: The parser follows the YAML 1.2 specification and the JSON / ECMA-404 standards, which are stable and rarely change. When the standards change (or when the common-subset definition needs to grow to cover more real-world YAML files), the converter is updated to match the current authoritative source.

References

• YAML 1.2 Specification, the canonical source for the YAML language. The converter follows the YAML 1.2 subset (mappings, sequences, scalars, indentation) and rejects features outside that subset with explicit errors.
• ECMA-404: The JSON Data Interchange Format, the canonical source for JSON syntax. The converter emits canonical ECMA-404 JSON via JavaScript's built-in JSON.stringify.
• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, the IETF version of ECMA-404, byte-identical for practical purposes.
• Kubernetes API documentation, useful for understanding the YAML structure of Pods, Deployments, Services, and other Kubernetes resources.
• GitHub Actions workflow syntax, the canonical YAML schema for GitHub Actions, including the on/jobs/steps hierarchy.
• Docker Compose specification, the YAML schema for docker-compose.yml files, including services, networks, volumes, and config.