Convert between JSON and YAML
- Dashboard
- Documentation
- API
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.parseandJSON.stringifywithout dependency. - Browser-side storage:
localStorage,sessionStorage, IndexedDB. - AJAX and
fetchrequests. - 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 code01234becomes the integer1234, and a country nameNO(Norway) becomesfalse. 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/offas booleans, which 1.2 removed. Behaviours also differ on base 8 numbers. - Implicit dates:
2024-01-15without 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:
- Paste your source document (JSON or YAML) into the input field.
- Pick the desired conversion direction (JSON to YAML, or YAML to JSON).
- Click the conversion button: the formatted result appears in the output area.
- 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 toolGET https://cdrn.fr/api/v1/tools/json-yaml-converter- returns the schema for this toolPOST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute- runs this tool with a JSON payload