Convert between JSON and YAML

convert JSON to YAML (and back) while preserving the structure, with configurable indentation. Useful to migrate a configuration between .json and .yaml files

What is this JSON / YAML converter for?

This tool turns a YAML document into JSON and vice versa, preserving the data structure (objects, arrays, scalar types). JSON to YAML conversion, or YAML to JSON, is a common operation in development: you generate an OpenAPI YAML file from a JSON spec, you convert the output of a REST API to YAML to commit it to a configuration repository, you translate a Kubernetes YAML manifest to JSON to pass to kubectl --dry-run=client -o json, or you align a GitHub Actions workflow with a JSON schema. More broadly, it is the bridge between the data interchange world (JSON) and that of hand-editable configuration (YAML).

YAML vs JSON: direct comparison

JSON and YAML address similar needs but different use cases. The following table summarises the main technical differences, useful to choose between the two depending on the context.

Criterion JSON YAML
Human readability Medium (braces, quotes everywhere) High (indentation, little punctuation)
Verbosity More verbose More concise
Comments Not supported Supported (# comment)
Multiple documents in a single file No Yes, via the --- separator
Anchors and aliases (reuse) No Yes (&anchor and *anchor)
Type system Strict (string, number, bool, null, array, object) Implicit coercion (yes, no, null, dates, interpreted scalars)
Parsing performance Very fast, native parsers everywhere Slower, much broader grammar
Adoption for REST APIs De facto standard Rare
Adoption for configuration Rare (except package.json, tsconfig.json) De facto standard (Kubernetes, CI/CD, Ansible)

When to use JSON?

JSON is the obvious choice as soon as one program talks to another. Its typical use cases:

  • REST and GraphQL APIs: request and response payloads.
  • Data exchange between microservices and message queues.
  • Native JavaScript code: JSON.parse and JSON.stringify without dependency.
  • Browser-side storage: localStorage, sessionStorage, IndexedDB.
  • AJAX and fetch requests.
  • Binary or stream-oriented variants: BSON (MongoDB), JSON Lines (logs, ML datasets), MessagePack.
  • Configuration of JS / TS tooling: package.json, tsconfig.json, composer.json.

When to use YAML?

YAML is the obvious choice as soon as a human regularly edits the file. Its typical use cases:

  • Docker Compose (docker-compose.yml) and stack profiles.
  • Kubernetes manifests (Deployment, Service, Ingress, Helm charts).
  • Ansible playbooks and inventories.
  • CI/CD pipelines: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines.
  • OpenAPI / Swagger and AsyncAPI specifications.
  • Annotated application configuration (Symfony, Spring Boot, Rails) where comments are useful.
  • Files edited frequently by hand, where conciseness and readability matter more than parsing speed.

Common pitfalls in YAML

YAML is more permissive than JSON, which makes it a powerful but treacherous format. The most frequent pitfalls:

  • Indentation: tabs are forbidden by the specification, only spaces are valid. Mixing the two or changing the number of spaces within the same block breaks parsing.
  • Automatic scalar coercion: yes, no, on, off, true, false, null, None, ~ are parsed as booleans or null. Tricky example: an unquoted postal code 01234 becomes the integer 1234, and a country name NO (Norway) becomes false. Always quote ambiguous strings.
  • Multi-line strings: | (block literal) keeps line breaks as is, whereas > (folded) replaces line breaks with spaces. The chomping indicators - and + adjust the behaviour on the final break.
  • YAML 1.1 vs 1.2: 1.1 (still very widespread, for example via PyYAML by default) treats yes/no/on/off as booleans, which 1.2 removed. Behaviours also differ on base 8 numbers.
  • Implicit dates: 2024-01-15 without quotes is interpreted as a date object by some parsers, not as a string.

Side-by-side examples

The same document, expressed in JSON then in YAML. Simple configuration of an application with its dependencies and environment:

JSON version

{
    "name": "cdrn-app",
    "version": "1.14.2",
    "environment": "production",
    "dependencies": {
        "php": "^8.3",
        "symfony/framework-bundle": "^7.0",
        "doctrine/orm": "^3.0"
    },
    "features": ["cache", "mailer", "queue"],
    "debug": false
}

Equivalent YAML version

# Application configuration
name: cdrn-app
version: 1.14.2
environment: production
dependencies:
    php: '^8.3'
    symfony/framework-bundle: '^7.0'
    doctrine/orm: '^3.0'
features:
    - cache
    - mailer
    - queue
debug: false

The YAML version is about 25% shorter in characters, accepts a comment at the top and reads like a list of properties without syntactic noise.

How to use the converter

Steps to convert your data:

  1. Paste your source document (JSON or YAML) into the input field.
  2. Pick the desired conversion direction (JSON to YAML, or YAML to JSON).
  3. Click the conversion button: the formatted result appears in the output area.
  4. Check the rendering, then use the copy button to get the result onto your clipboard.

The conversion is performed locally in your browser or via a dedicated server route depending on the tooling: no sensitive data is kept.

Frequently asked questions

JSON or YAML for my configuration files?

If the ecosystem mandates a format (Kubernetes in YAML, package.json in JSON), follow the convention. Otherwise, prefer YAML for long, annotated configurations that you edit by hand, and JSON for configurations generated by a program or consumed by code. The availability of useful comments is often the deciding argument in favour of YAML.

How do I keep comments during a YAML to JSON to YAML round-trip?

You cannot. JSON does not support comments: as soon as YAML is converted to JSON, comments are lost permanently. To preserve comments during programmatic edits, use a parser that keeps the formatting, like ruamel.yaml in Python in round-trip mode, or avoid going through JSON entirely.

Why does my YAML file parse correctly locally but fail in production?

Frequent causes: different parser versions (YAML 1.1 vs 1.2), tabs introduced by an editor, unquoted values that look like booleans (NO, off) or numbers (01234), file encoding (badly handled UTF-8 BOM). Systematically quote ambiguous strings and pin the parser version in your project.

Is JSON a subset of YAML?

Since YAML 1.2, yes in practice: any valid JSON document is a valid YAML 1.2 document. The reverse is false: a YAML document that uses comments, anchors, implicit dates or multiple documents in a file cannot be expressed directly in JSON without information loss.

What alternatives to JSON and YAML should I know?

TOML: popular for config (Cargo, pyproject.toml), a good readability/explicit-typing compromise. INI: very simple, but no standard nested structure. XML: verbose, but still relevant for SOAP and some legacy Java configs. HCL: used by Terraform. JSON5 and JSONC: JSON extensions that allow comments and trailing commas.

What is the size of YAML vs JSON?

At equivalent structure, YAML is usually 15 to 30% shorter in bytes, thanks to the absence of quotes around keys and most strings, and the absence of braces. On the wire (HTTP transport), minified JSON stays comparable, but YAML stays more compact in readable form. For raw parsing performance, JSON is several times faster, which justifies its use for high-traffic APIs.

Example request

curl -X POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute \
  -H "Content-Type: application/json" \
  -d '{"json":"...","space_tabulation":1}'

Input schema

Field Type Required Default
json text
space_tabulation integer

Endpoints

  • GET https://cdrn.fr/api/v1/tools - lists every available tool
  • GET https://cdrn.fr/api/v1/tools/json-yaml-converter - returns the schema for this tool
  • POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute - runs this tool with a JSON payload