YAML to JSON Converter

Why convert YAML to JSON?

YAML is the human-facing format. JSON is the machine-facing format. The conversion from YAML to JSON is useful when you need to bridge the two worlds — validating a config, feeding it to an API, or simply understanding what a complex YAML document actually resolves to after anchors, aliases, and type coercions are applied.

The most common real-world use case: debugging a Kubernetes manifest or GitHub Actions workflow that behaves unexpectedly. Converting to JSON forces the document to its fully-resolved, type-inferred form, making it immediately obvious if a value is a string when it should be an integer, or null when you expected a boolean.

Kubernetes manifests — debugging with JSON

When a Kubernetes resource isn't behaving as expected, converting the manifest YAML to JSON is often the fastest way to understand what the API server actually received. kubectl get deployment my-app -o json returns the server-side representation in JSON, which you can compare against your source YAML to find mismatches.

# Get the live spec as JSON and pipe to jq
kubectl get deployment my-app -o json | jq '.spec.template.spec.containers[0]'

# Diff your local YAML against the cluster state
kubectl diff -f deployment.yaml

A frequent Kubernetes YAML trap: the resources.limits.memory field. 128Mi is a string, not a number — the Mi suffix makes it so. Converting to JSON confirms what type the API server interprets it as and catches values that should be quoted but aren't.

GitHub Actions workflow debugging

GitHub Actions workflows fail in ways that are not obvious from the YAML source. Two of the most common:

The on key ambiguity. Bare on: in some YAML parsers is interpreted as boolean true. GitHub's parser handles it correctly, but pasting the workflow into this converter will show you exactly what value the on key resolves to in your environment's parser.

Expression vs literal string. env.MY_VAR: $${ secrets.MY_SECRET } is a GitHub expression, not a string. If you see it quoted differently than expected in JSON output, the quotes are either missing or misplaced in the YAML source.

YAML anchors and aliases — what JSON sees

YAML anchors (&anchor-name) and aliases (*anchor-name) are a DRY mechanism for reusing values. They have no equivalent in JSON — this converter resolves them to their full expanded values:

# YAML with anchor and alias
defaults: &defaults
  retries: 3
  timeout: 30

production:
  <<: *defaults
  host: prod.example.com

staging:
  <<: *defaults
  host: staging.example.com

// Resulting JSON — anchors fully resolved
{
  "defaults": { "retries": 3, "timeout": 30 },
  "production": { "retries": 3, "timeout": 30, "host": "prod.example.com" },
  "staging": { "retries": 3, "timeout": 30, "host": "staging.example.com" }
}

Converting to JSON is the fastest way to verify that a merge key (<<:) is applying the correct values and that overrides are working as expected.

Validating YAML with a JSON schema

JSON Schema is the most widely supported config validation format. Most schema validators accept JSON input — not YAML. Converting your YAML to JSON first lets you run it through tools like jsonschemavalidator.net or the ajv CLI to verify that your config satisfies the schema. Kubernetes itself validates manifests against its OpenAPI schema before admission — which is why type mismatches that look fine in YAML cause ValidationError at apply time.

Frequently Asked Questions