How to Convert JSON to YAML Online

JSON is the language of APIs. YAML is the language of configuration. If you are working with Kubernetes, Docker Compose, Ansible, or GitHub Actions, you write YAML. If your data or settings come from an API or a tool that exports JSON, you eventually need to convert between the two. This guide shows how to do that correctly and explains where the formats differ.

JSON vs YAML: the key differences

Both formats represent the same data structures — objects, arrays, strings, numbers, booleans, and null. The differences are in how they express those structures:

What a JSON-to-YAML conversion looks like

Take a typical service configuration in JSON:

{
  "service": {
    "name": "api-server",
    "port": 8080,
    "replicas": 3,
    "env": ["production", "us-east-1"],
    "healthCheck": {
      "enabled": true,
      "path": "/health",
      "intervalSeconds": 30
    }
  }
}

The equivalent YAML output:

service:
  name: api-server
  port: 8080
  replicas: 3
  env:
    - production
    - us-east-1
  healthCheck:
    enabled: true
    path: /health
    intervalSeconds: 30

The data is identical. YAML uses indentation where JSON uses braces, and the result is visibly less cluttered — especially for deeply nested configuration.

Common DevOps use cases

Kubernetes manifests

Kubernetes accepts both JSON and YAML, but almost all real-world manifests are written in YAML. If you have JSON output from a tool like Helm or Terraform and need to review or commit it as a Kubernetes manifest, converting to YAML makes it more readable and easier to annotate with comments.

Docker Compose

Docker Compose only accepts YAML (docker-compose.yml). If you generate service configuration programmatically as JSON, convert it to YAML before using it with Compose.

GitHub Actions and CI/CD pipelines

GitHub Actions workflows are YAML. If you build pipeline configuration generators that output JSON, you will need a conversion step before the output is usable.

Ansible playbooks

Ansible uses YAML for playbooks and inventory files. JSON from external sources (APIs, CMDBs) needs to be converted before it can be used directly in playbook variables.

What to watch out for during conversion

• Indentation errors — YAML is whitespace-sensitive. Always use spaces, not tabs. A converter handles this automatically; manually editing the output is where errors creep in.
• String quoting — YAML can usually omit quotes, but strings that look like other types (booleans: yes, no, true, false; numbers; null) must be quoted to be treated as strings. A good converter handles this.
• Special characters in strings — Strings with colons, hash symbols, or other YAML-meaningful characters need to be quoted in YAML to avoid parse errors.
• JSON is valid YAML — If you need to, you can use JSON syntax directly inside a YAML file. This is not ideal but it works.

FAQ

Is YAML better than JSON for configuration files?

YAML is more human-readable because it uses indentation instead of braces and supports comments. JSON is better for data exchange between programs because it is simpler to parse. Use YAML for config files humans write and read, JSON for data transfers between systems.

Can all JSON be converted to YAML?

Yes. Every valid JSON document is a subset of YAML. JSON-to-YAML conversion is lossless — all keys, values, arrays, and objects are preserved exactly.

Why does Kubernetes use YAML instead of JSON?

Kubernetes manifests are written by humans. YAML's readability and comment support make it a better choice for authoring and reviewing in version control. Kubernetes does accept JSON, but YAML is the convention.