Skip to content

JSON to YAML Converter

Paste JSON, get YAML instantly. Live conversion in your browser. K8s/Compose-ready, 2/4-space indent, smart quoting. 100% private, no upload.

No Tracking Runs in Browser Free
Options · 2 spaces · auto · block
Indent
Style
0 chars
YAML Output
0 lines
Reviewed for RFC 8259 compliance, YAML 1.2 spec output, and Norway-problem handling correctness — Go Tools Engineering Team · May 4, 2026

What is YAML and Why Convert from JSON?

YAML (YAML Ain't Markup Language) is a human-readable data serialization format designed for configuration files, infrastructure-as-code, and anywhere a human writes data that a machine will read. Its indentation-based syntax requires no braces or brackets, making it far more legible than JSON for complex nested structures. Kubernetes, Helm, Ansible, Docker Compose, GitHub Actions, CircleCI, and virtually every cloud-native tool uses YAML as its primary configuration format. Converting JSON to YAML is therefore one of the most common tasks in DevOps and backend development — you receive a resource definition from an API in JSON, and you need a YAML manifest to commit to version control.

This tool has four important differentiators compared to typical online converters:

**1. Norway Problem — Auto-Safe Quoting.** The single biggest footgun in JSON-to-YAML conversion is the YAML Norway Problem. In YAML 1.1 (which millions of production parsers still use, including older Kubernetes, PyYAML, Ansible, and Ruby's Psych), the bare strings yes, no, on, off, y, and n are parsed as boolean true/false values. This famously bit the ISO country code for Norway ("NO" → false) and has caused real production outages in Kubernetes configs. YAML 1.2 fixed this, but your parsers may not be on 1.2. This tool's default Auto quote mode uses the eemeli/yaml library with the YAML 1.1 schema, so it automatically wraps any Norway-problem string in quotes, guaranteeing safe round-trips through both YAML 1.1 and 1.2 parsers. Learn more in our companion article at The YAML Norway Problem and JSON-YAML Differences.

**2. Key Order Preservation.** Unlike some converters that sort keys alphabetically, this tool preserves the original key insertion order from your JSON — matching the behavior of JSON.parse() in all modern JavaScript engines. This matters for Kubernetes manifests (where apiVersion and kind are expected first by convention), OpenAPI specs (where info appears before paths), and any config where field ordering is meaningful for readability or diffs.

**3. Big-Number Precision Caveat.** JSON numbers larger than 2^53 - 1 (9007199254740991) cannot be represented exactly in JavaScript's IEEE 754 double-precision float. When JSON.parse() reads a large integer like a Kubernetes resourceVersion field (which is a 64-bit integer on the server), it silently truncates it. This is a fundamental browser JavaScript limitation that affects every browser-based JSON tool, including this one. The safe workaround is to ensure large integers are stored as strings in your JSON before converting. This tool documents this behavior honestly in the Number Precision Loss common error below.

**4. 100% Browser-Based Privacy.** Your JSON data — which often contains API keys, database credentials, internal service configurations, and production secrets — never leaves your browser. No data is sent to any server. You can verify this in your browser's Network tab. This is the only safe way to handle sensitive configuration data in an online tool. See our companion tool for the reverse direction at YAML to JSON Converter, and our JSON Formatter if you need to validate and pretty-print JSON before converting.

YAML's human-readable nature comes with a tradeoff: it has more parsing edge cases than JSON. Beyond the Norway Problem, YAML has octal number quirks (0777 is parsed as 511 in YAML 1.1), multiline string syntax (| for literal, > for folded), anchor and alias references (&anchor and *alias), and multiple document support (--- separator). JSON has none of these complexities — it is a strict, minimal format with only six data types. For machine-to-machine data exchange, JSON is almost always the better choice. For human-edited configuration files where readability and comments matter, YAML wins. This converter gives you the best of both: use JSON programmatically, convert to YAML for your infrastructure.

// Convert JSON to YAML in Node.js using the eemeli/yaml library
import { Document } from 'yaml';

const data = JSON.parse('{"apiVersion":"apps/v1","kind":"Deployment"}');

// version: '1.1' ensures Norway-problem strings (yes/no/on/off/y/n)
// are automatically quoted in the output for YAML 1.1 parser safety
const doc = new Document(data, { version: '1.1' });

const yamlString = doc.toString({
  indent: 2,
  lineWidth: 0,         // disable line wrapping
  defaultStringType: 'PLAIN',   // Auto mode: only quote when needed
});

console.log(yamlString);
// apiVersion: apps/v1
// kind: Deployment

Key Features

Live Conversion

YAML output updates instantly as you type or paste JSON — no Convert button needed. Large inputs (>200KB) automatically switch to manual mode to keep the browser responsive.

Indent 2 or 4 Spaces

Switch between 2-space (standard for Kubernetes, Docker Compose, and GitHub Actions) and 4-space (Ansible convention) indentation. YAML tabs are forbidden — this tool always uses spaces.

Auto-Safe Quoting (Norway-safe)

The default Auto mode uses the YAML 1.1 schema to automatically quote strings like "no", "yes", "on", "off", "y", and "n" that would be misread as booleans by YAML 1.1 parsers, preventing production misconfigurations.

Block and Flow Styles

Block style produces indented, human-readable YAML ideal for manifests and config files. Flow style produces compact, inline YAML similar to JSON — useful for documentation snippets or tools that prefer minimal output.

100% Browser-Based Privacy

All conversion runs locally in your browser using JavaScript. Your JSON data — including API keys, credentials, and production configs — is never sent to any server, never logged, and never stored.

Handles K8s, Compose, and Terraform Files

Optimized for real-world DevOps use cases: Kubernetes manifests, Docker Compose stacks, Helm chart values, GitHub Actions workflows, OpenAPI specs, and Terraform JSON plan outputs — with examples for each.

Examples

Kubernetes Deployment

{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"my-app","namespace":"production","labels":{"app":"my-app","version":"1.0.0"}},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"my-app"}},"template":{"metadata":{"labels":{"app":"my-app"}},"spec":{"containers":[{"name":"my-app","image":"my-app:1.0.0","ports":[{"containerPort":8080}],"resources":{"requests":{"memory":"64Mi","cpu":"250m"},"limits":{"memory":"128Mi","cpu":"500m"}}}]}}}}

Convert a Kubernetes Deployment manifest from JSON API response format to YAML for applying with kubectl apply -f

Docker Compose

{"version":"3.9","services":{"web":{"image":"nginx:1.25-alpine","ports":["80:80","443:443"],"environment":{"NGINX_HOST":"example.com","NGINX_PORT":"80"},"depends_on":["db"],"restart":"unless-stopped"},"db":{"image":"postgres:16-alpine","environment":{"POSTGRES_DB":"mydb","POSTGRES_USER":"admin","POSTGRES_PASSWORD":"secret"},"volumes":["pgdata:/var/lib/postgresql/data"]}},"volumes":{"pgdata":{}}}

Convert a Docker Compose service definition from JSON to the YAML format required by docker compose up

GitHub Actions Workflow

{"name":"CI","on":{"push":{"branches":["main"]},"pull_request":{"branches":["main"]}},"jobs":{"build":{"runs-on":"ubuntu-latest","steps":[{"uses":"actions/checkout@v4"},{"name":"Set up Node.js","uses":"actions/setup-node@v4","with":{"node-version":"20","cache":"pnpm"}},{"name":"Install dependencies","run":"pnpm install --frozen-lockfile"},{"name":"Run tests","run":"pnpm test"}]}}}

Convert a GitHub Actions CI workflow definition from JSON to YAML for committing to .github/workflows/

OpenAPI Spec

{"openapi":"3.0.3","info":{"title":"User API","version":"1.0.0","description":"Manage application users"},"paths":{"/users":{"get":{"summary":"List users","operationId":"listUsers","parameters":[{"name":"limit","in":"query","schema":{"type":"integer","default":20}}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/User"}}}}}}}},"/users/{id}":{"get":{"summary":"Get user","operationId":"getUser","parameters":[{"name":"id","in":"path","required":true,"schema":{"type":"string"}}],"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"User":{"type":"object","properties":{"id":{"type":"string"},"name":{"type":"string"},"email":{"type":"string","format":"email"}}}}}}

Convert an OpenAPI 3.0 spec from JSON to YAML — the preferred format for Swagger UI, Redoc, and most API tooling

package.json

{"name":"my-app","version":"1.0.0","description":"A sample Node.js application","private":true,"scripts":{"dev":"vite","build":"tsc && vite build","preview":"vite preview","test":"vitest","lint":"eslint . --ext .ts,.tsx"},"dependencies":{"react":"^18.3.0","react-dom":"^18.3.0"},"devDependencies":{"typescript":"^5.4.0","vite":"^5.2.0","vitest":"^1.5.0","eslint":"^8.57.0","@types/react":"^18.3.0"},"engines":{"node":">=20.0.0","pnpm":">=9.0.0"}}

Convert a typical Node.js package.json to YAML — useful for migrating project config to tools that prefer YAML

Terraform JSON Plan

{"format_version":"1.0","terraform_version":"1.7.4","variables":{"region":{"value":"us-east-1"}},"planned_values":{"root_module":{"resources":[{"address":"aws_s3_bucket.main","mode":"managed","type":"aws_s3_bucket","name":"main","values":{"bucket":"my-app-assets","force_destroy":false,"tags":{"Environment":"production","ManagedBy":"terraform"}}}]}},"resource_changes":[{"address":"aws_s3_bucket.main","mode":"managed","type":"aws_s3_bucket","name":"main","change":{"actions":["create"],"before":null,"after":{"bucket":"my-app-assets","force_destroy":false}}}]}

Convert a Terraform JSON plan output to YAML for human review, GitOps audit trails, and CI/CD pipelines — a differentiator most converters miss

How to Use

  1. 1

    Paste Your JSON

    Enter or paste your JSON data into the input field above. You can also click 'Load example' to try a sample like a Kubernetes Deployment, Docker Compose file, or Terraform plan.

  2. 2

    See Live YAML Output

    YAML appears instantly in the output panel. Adjust Options (indent 2/4, quotes Auto/Double/Single, style Block/Flow) to match your target tool's requirements.

  3. 3

    Copy or Download

    Click Copy to grab the YAML to your clipboard, or Download to save it as a .yaml file ready for kubectl apply, docker compose up, or any other tool.

Common Conversion Pitfalls

Trailing Commas

JSON does not allow a comma after the last element in an object or array. This is extremely common when copying from JavaScript code, which does allow trailing commas. Remove the final comma before converting.

✗ Wrong
{"name": "Alice", "role": "admin",}
✓ Correct
{"name": "Alice", "role": "admin"}

Single Quotes

JSON requires double quotes for all string values and object keys. Single quotes are valid in JavaScript and Python, but are a syntax error in JSON.

✗ Wrong
{'name': 'Alice', 'active': true}
✓ Correct
{"name": "Alice", "active": true}

Unquoted Keys

All JSON object keys must be enclosed in double quotes. Unquoted keys are valid in JavaScript object literals but will cause a parse error in strict JSON.

✗ Wrong
{name: "Alice", role: "admin"}
✓ Correct
{"name": "Alice", "role": "admin"}

Comments Not Allowed

Standard JSON does not support comments of any kind — not //, /* */, or #. If you need comments in configuration, use YAML (which supports # comments) or JSONC (JSON with Comments, used by VS Code). Strip all comments before using data as JSON.

✗ Wrong
{"port": 8080 // HTTP port}
✓ Correct
{"port": 8080}

YAML Norway Problem (auto-handled in Auto mode)

In YAML 1.1 parsers (used by Kubernetes, Ansible, PyYAML, Ruby Psych), bare strings yes, no, on, off, y, and n are parsed as boolean true/false instead of strings. This tool's Auto mode automatically quotes these values in the YAML output to guarantee safe round-trips through any YAML 1.1 or 1.2 parser. If you select Double or Single quote mode, all strings are explicitly quoted, which also avoids the problem — but the Auto mode is the most natural-looking output.

✗ Wrong
# JSON input: {"country": "no", "enabled": "yes"}
# YAML without quoting (dangerous):
country: no
enabled: yes
# YAML 1.1 parser reads: country=false, enabled=true
✓ Correct
# YAML with Auto quoting (safe):
country: 'no'
enabled: 'yes'
# YAML 1.1 parser reads: country="no", enabled="yes"

Number Precision Loss for Large Integers

JavaScript can only represent integers exactly up to 2^53 - 1 (9007199254740991). JSON integers larger than this — such as Kubernetes resourceVersion fields (which are int64 on the server) — are silently rounded when parsed by JSON.parse(). This truncated number then appears in the YAML output. This is a fundamental browser JavaScript limitation affecting all browser-based JSON tools. The safe workaround is to store large integers as strings in your JSON before converting.

✗ Wrong
// JSON input (resourceVersion is int64 on K8s server)
{"resourceVersion": 9007199254740993}
// JavaScript reads it as: 9007199254740992 (precision lost)
// YAML output will contain the wrong number
✓ Correct
// Store large integers as strings to preserve precision
{"resourceVersion": "9007199254740993"}
// YAML output: resourceVersion: '9007199254740993' (exact)

Common Use Cases

Kubernetes Manifests
Convert JSON API responses from kubectl get -o json or the Kubernetes API into YAML manifests for GitOps workflows, Kustomize overlays, and kubectl apply -f deployments.
Docker Compose Files
Transform docker inspect JSON output or programmatically generated service configs into docker-compose.yaml files compatible with docker compose up and Docker Stack deployments.
Helm Chart Values
Convert JSON configuration exports into YAML values files for Helm chart deployments, enabling version-controlled infrastructure configuration with clean YAML syntax.
GitHub Actions Workflows
Build GitHub Actions workflow definitions programmatically in JSON and convert to the .github/workflows/*.yaml format required by the GitHub Actions runner.
OpenAPI Specifications
Convert OpenAPI/Swagger specs from the JSON format returned by many frameworks (FastAPI, SpringDoc) to the YAML format preferred by Swagger UI, Redoc, and API gateway tooling.
Configuration Migration
Migrate application configuration stored in JSON (appsettings.json, config.json) to YAML format for tools that require or prefer YAML, adding the ability to use comments for documentation.

Technical Details

RFC 8259 Compliant JSON Parsing
JSON input is parsed using the browser's native JSON.parse(), which is fully RFC 8259 compliant. This provides accurate syntax error messages including position information (best-effort line and column numbers) and handles all JSON data types: strings, numbers, booleans, null, arrays, and objects.
YAML 1.2 Output via eemeli/yaml Document API with YAML 1.1 Schema
YAML is generated using the eemeli/yaml library (v2.8+, CVE-safe) via its Document API with version: '1.1'. This combination produces YAML 1.2-compliant output while applying YAML 1.1 quoting rules — meaning Norway-problem strings (yes/no/on/off/y/n) are automatically quoted in the output, making it safe for both YAML 1.1 and 1.2 parsers. Line wrapping is disabled (lineWidth: 0) to preserve long strings intact.
100% Browser-Based — No Upload, No Server
All processing happens entirely in your browser's JavaScript engine. No data is transmitted over the network at any point. Inputs larger than 200KB automatically switch from live mode to manual mode (requiring an explicit Convert click) to keep the browser responsive and prevent main-thread blocking during heavy serialization.

Best Practices

Always Use Auto Quote Mode for DevOps Configs
When converting JSON for use in Kubernetes, Helm, Ansible, Docker Compose, or GitHub Actions, always use the default Auto (Norway-safe) quote mode. YAML 1.1 parsers in these tools will silently misinterpret bare yes, no, on, off, y, and n as booleans — Auto mode prevents this transparently.
Use 2-Space Indent for Cloud-Native Tools
Kubernetes, Docker Compose, GitHub Actions, and Helm all use 2-space indentation by convention. Using 4-space indentation in these files is valid YAML but will create inconsistency with community examples, auto-generated configs, and your team's existing manifests.
Store Large Integers as Strings Before Converting
Kubernetes resourceVersion, uid, and other int64 fields from the API server can exceed JavaScript's safe integer range (2^53 - 1). If you need exact numeric precision, store these values as JSON strings before converting. This is especially important for kubectl get -o json output that includes server-side generated fields.
Validate JSON First
If your JSON source is hand-written or comes from a system that occasionally produces invalid output (trailing commas, unquoted keys, comments), validate it with a JSON formatter before converting. Use our JSON Formatter to catch and fix syntax errors first, then convert the clean JSON to YAML.
Prefer Block Style for Files Going into Version Control
Block style YAML produces clean, human-readable diffs in Git because each field appears on its own line. Flow style (compact, inline) makes diffs harder to read and review. Reserve Flow style for embedding short YAML snippets in documentation or for tools that require compact output.

Frequently Asked Questions

How do I convert JSON to YAML online?
Paste your JSON into the input field above. The tool converts it to YAML instantly in your browser — no button click needed. You can adjust indentation (2 or 4 spaces), quoting style (Auto, Double, or Single), and output style (Block or Flow) from the Options panel. Once the YAML appears in the output area, click Copy to grab it to your clipboard or Download to save it as a .yaml file. Everything runs locally — your data never leaves your device.
What is the YAML Norway Problem and how does this tool handle it?
The YAML Norway Problem refers to a quirk in YAML 1.1 specification where bare strings like "no", "yes", "on", "off", "y", and "n" are parsed as boolean values (false/true) instead of strings. This caused a famous real-world issue where the ISO country code for Norway ("NO") was misread as the boolean false in Ansible playbooks and Kubernetes configs. In YAML 1.2, this was fixed — bare strings are always strings. However, millions of production parsers (older Kubernetes versions, PyYAML, Ansible, Ruby's Psych) still use YAML 1.1. This tool's Auto quote mode (the default) automatically wraps any Norway-problem strings in quotes so they round-trip safely through both YAML 1.1 and 1.2 parsers. When Norway-problem strings are detected in your input, a warning banner lists exactly which values were auto-quoted.
Why does the Norway Problem matter for Kubernetes and DevOps?
Kubernetes YAML manifests, Helm chart values, Ansible playbooks, and GitHub Actions workflows are all parsed by tools that historically used YAML 1.1. If you have a config key with the value "no" (for example, a country code, an enabled flag in string form, or a custom boolean-like field), a YAML 1.1 parser will silently convert it to the boolean false. This can cause service misconfigurations that are extremely difficult to debug because the YAML appears correct when viewed as text but behaves differently when parsed. Always use Auto quote mode when converting JSON for use in Kubernetes or any DevOps toolchain to guarantee safe round-trips.
Should I use 2-space or 4-space indentation for YAML?
Use 2-space indentation for Kubernetes manifests, Helm values, Docker Compose files, and GitHub Actions workflows — these tools are designed around 2-space YAML and it is the community convention. Use 4-space indentation for Ansible playbooks (which follow a 4-space convention) and when your team or organization has a style guide mandating it. YAML forbids tabs entirely — all indentation must be spaces. This tool defaults to 2 spaces, which is the correct choice for the vast majority of cloud-native use cases.
How do I use this tool to create a Kubernetes manifest?
If you have a Kubernetes resource definition in JSON (from kubectl get deployment my-app -o json, an API response, or a Terraform resource block), paste it into the input field. Select 2 spaces indentation (the default) and Auto quotes (the default, which handles the Norway Problem). The YAML output is immediately ready for kubectl apply -f. You can also click Download to save the file with a .yaml extension and pipe it directly into kubectl apply -f -. The K8s Deployment example above shows a complete deployment manifest you can load and modify.
How do I convert a Docker Compose JSON to YAML?
Paste your Docker Compose JSON into the input field. Use 2-space indentation (Docker Compose convention) and Block style. The output YAML is compatible with docker compose up, docker compose config, and Docker Stack. A common scenario is exporting a running stack's configuration with docker inspect and then converting it back to a compose.yaml file. The Docker Compose example above includes service definitions with ports, environment variables, volumes, and depends_on.
Can JSON numbers larger than 2^53 lose precision when converting to YAML?
Yes. This is a fundamental JavaScript limitation: the IEEE 754 double-precision float used by JavaScript's Number type can only represent integers exactly up to 2^53 - 1 (9007199254740991). Any integer beyond that — such as Kubernetes resourceVersion fields (which are int64 on the server) — will be silently rounded when parsed by JSON.parse(). For example, the value 9007199254740993 becomes 9007199254740992 in JavaScript, and this truncated number will appear in your YAML output. This affects all browser-based JSON tools, not just this one. The safe workaround is to store large integers as strings in your JSON ("resourceVersion": "9007199254740993") — they will appear as YAML strings without any precision loss.
Does the converter preserve the original key order from my JSON?
Yes. The eemeli/yaml library used by this tool preserves insertion order, which matches the behavior of JSON.parse() in all modern JavaScript engines (V8, SpiderMonkey, JavaScriptCore). Keys appear in the YAML output in the same order they appeared in the JSON input. This is important for Kubernetes manifests and OpenAPI specs where field ordering is often meaningful for readability and diffs.
When should I use JSON versus YAML?
Use JSON when: you are building APIs and web services (JSON is the universal interchange format), when machine parsing speed matters, when you need strict type safety, or when the consumer is a JavaScript/TypeScript application. Use YAML when: writing configuration files intended for human editing (Kubernetes manifests, CI/CD pipelines, Ansible playbooks, Helm values), when you want comments in your config, or when readability is more important than strictness. A helpful rule: if a machine writes it or reads it first, use JSON; if a human writes it and a machine reads it, use YAML.
How can I convert JSON to YAML on the command line?
The most popular approach is combining yq and jq. Install yq (Mike Farah's version, not the Python one): brew install yq on macOS or wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/local/bin/yq for Linux. Then run: cat input.json | yq -P to pretty-print as YAML. Alternatively: yq -o yaml input.json or cat input.json | python3 -c "import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False)". For Kubernetes specifically: kubectl get deployment my-app -o yaml converts directly from the cluster API.
How do I convert JSON to YAML in Python, Node.js, or Go?
In Python: import json, yaml; yaml.dump(json.load(open('input.json')), open('output.yaml', 'w'), default_flow_style=False) using PyYAML, or ruamel.yaml for round-trip fidelity. In Node.js: import { Document } from 'yaml'; const doc = new Document(JSON.parse(input), { version: '1.1' }); const result = doc.toString({ indent: 2, lineWidth: 0 }) — this is the same library and approach used by this tool. In Go: import gopkg.in/yaml.v3; json.Unmarshal(jsonBytes, &data); yaml.Marshal(data) — note that Go YAML v3 uses YAML 1.1 by default, so Norway-problem strings will be auto-quoted.
Is my JSON data sent to any server when I use this tool?
No. All conversion happens entirely in your browser using JavaScript. Your JSON data is never transmitted over the network, never stored on any server, and never logged or analyzed. This makes the tool safe to use with API keys, database credentials, internal configuration files, production Kubernetes manifests, and any other sensitive data. The tool uses no cookies for your input data and no third-party analytics that would capture your paste. You can verify this by opening your browser's Network tab — you will see zero requests triggered by pasting JSON.
Is there a file size limit for JSON input?
There is no hard file size limit, but large inputs (over 200KB) automatically switch from live conversion to manual mode. In manual mode, a Convert button appears and conversion runs only when you click it — this prevents the browser's main thread from blocking for 200-500ms on every keystroke. For very large JSON files (multi-megabyte), consider using command-line tools like yq or jq for better performance. The tool efficiently handles typical real-world payloads like full Kubernetes namespace dumps, large OpenAPI specs, and multi-service Docker Compose files.

Related Tools

View all tools →