Convert YAML to JSON
online, free & instant

Valid JSON from YAML in three steps

No account. No upload. No nonsense.

Related JSON tools

Common questions answered

Converting YAML to JSON

YAML to JSON conversion is common when processing YAML configuration files programmatically or sending them to JSON-only APIs. Kubernetes manifests, Docker Compose files, and CI/CD pipelines use YAML, but the tools that validate or apply these configurations often work with JSON internally.

YAML is a superset of JSON, so any JSON is valid YAML. Going the other direction requires handling YAML-specific features: comments are stripped (JSON has none), anchors and aliases are resolved, multi-line strings are joined, and implicit type coercion (yes → true, 1.0 → number) is applied. This tool parses YAML safely and produces strict JSON.

# App configuration
name: my-app
version: 1.0.0
database:
  host: localhost
  port: 5432
features:
  - auth
  - logging

{
  "name": "my-app",
  "version": "1.0.0",
  "database": {
    "host": "localhost",
    "port": 5432
  },
  "features": [
    "auth",
    "logging"
  ]
}

Get the most out of this tool

• YAML comments are lost during conversion — save a copy of the original YAML if you need to preserve them.
• YAML implicit type coercion can be surprising: "yes" → true, "1.0" → 1 — quote values to force string type.
• Convert YAML to JSON and run through a JSON Schema validator to validate configuration files.

How YAML-to-JSON conversion works

YAML (YAML Ain't Markup Language) is a human-readable data serialization format designed as a superset of JSON. This superset relationship means every valid JSON document is valid YAML, but YAML supports additional features that JSON does not: comments, multi-line strings, anchors and aliases for reuse, custom tags, and multiple documents in one file separated by ---. Converting YAML to JSON discards these extra features, producing a JSON representation of the underlying data structure.

YAML uses indentation to denote structure rather than braces and brackets. A mapping (equivalent to a JSON object) uses key: value pairs on successive lines with consistent indentation. A sequence (equivalent to a JSON array) uses items prefixed with a dash (- item). The conversion process parses this indentation-based structure and emits the corresponding JSON syntax with explicit {} and [] delimiters.

YAML 1.1's boolean type coercion is a notorious source of bugs when converting to JSON. In YAML 1.1, the values yes, no, on, off, true, and false are all treated as boolean values. This causes problems with country codes like NO (Norway) or configuration values like on being silently converted to true. YAML 1.2 (adopted by most modern parsers) restricts boolean coercion to only true and false, eliminating this ambiguity.

YAML anchors (&anchor-name) and aliases (*anchor-name) provide a reuse mechanism: define a value once, reference it multiple times. When converting to JSON, aliases are expanded inline — each reference becomes a full copy of the anchored value. This expansion can significantly increase JSON file size if anchors are used for large repeated structures, but JSON has no equivalent reuse mechanism.

Multi-document YAML files (multiple documents separated by ---) present a choice during JSON conversion: produce a JSON array containing each document as an element, or require the user to select which document to convert. This is relevant for Kubernetes manifests, which commonly use multi-document YAML files containing multiple resource definitions (Deployment, Service, ConfigMap) separated by ---.

YAML comments (lines starting with #) carry important human-readable context — explaining why a value is set, marking deprecated fields, or providing examples. JSON has no comment syntax, so all YAML comments are discarded during conversion. If your YAML contains important comments that need to be preserved, consider including that information in dedicated description or documentation fields before converting.

When converting Kubernetes or Helm chart YAML to JSON, the result is useful for programmatic inspection and manipulation — for example, using jq to extract specific values, or feeding the configuration into JSON Schema validators. The converted JSON can also be used as input to this tool's JSONPath evaluator to query specific fields from complex multi-resource manifests.

When developers convert YAML to JSON

YAML-to-JSON conversion gotchas

• YAML 1.1 boolean coercion surprises: Country codes (NO, YES), toggle values (on, off), and other short strings may be silently converted to JSON booleans by YAML 1.1 parsers. Always quote these values in your YAML ("NO", "on") to ensure they remain strings in the JSON output.
• Losing YAML comments: JSON has no comment syntax, so all # comments in your YAML are dropped during conversion. If comments document important decisions or environment-specific values, extract that information into separate documentation before converting.
• Octal number interpretation: YAML 1.1 interprets numbers starting with 0 as octal — so 0777 becomes the integer 511 in the JSON output. Use YAML 1.2-compliant parsers or quote the value as a string to preserve the literal representation.
• Multi-document YAML losing documents: If your YAML file contains multiple --- separated documents and the converter only processes the first, subsequent documents are silently dropped. Verify that your converter handles multi-document YAML or split the file before converting.
• Anchor expansion causing large JSON: YAML anchors reference a single definition multiple times. JSON has no anchors — each reference is fully expanded. A large anchored value referenced 20 times in YAML becomes 20 full copies in JSON, potentially increasing file size dramatically.

Additional frequently asked questions