JSON to YAML Converter
Convert any JSON object or array to clean, readable YAML instantly. Preserves data types, handles nested objects and arrays with correct indentation, and produces valid YAML compatible with Kubernetes manifests, Docker Compose, GitHub Actions, Helm charts, Ansible playbooks, and any other YAML-based configuration format.
Convert any JSON object or array to clean, readable YAML instantly. Preserves data types, handles nested objects and arrays with correct indentation, and produces valid YAML compatible with Kubernetes manifests, Docker Compose, GitHub Actions, Helm charts, Ansible playbooks, and any other YAML-based configuration format.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
YAML — YAML Ain't Markup Language — is a data serialization format designed for human readability. Where JSON uses braces and brackets and requires every string to be quoted, YAML uses indentation to represent structure and omits quotes for most string values. The same data that takes four lines of JSON takes two lines of YAML. For configuration files that humans read and edit frequently — Kubernetes manifests, Docker Compose files, GitHub Actions workflows, Helm charts, Ansible playbooks, CI/CD pipeline definitions — YAML is significantly easier to read and maintain than JSON equivalents. YAML is a superset of JSON: every valid JSON document is also valid YAML, which is why JSON-to-YAML conversion is straightforward.
YAML and JSON share the same underlying data model: objects (mappings in YAML terminology), arrays (sequences), strings, numbers, booleans, and null. But YAML's type handling has some well-known quirks. Unquoted strings that look like other types are automatically coerced — the string yes becomes boolean true, no becomes false, null becomes the null value, and the two-letter country code NO for Norway was famously misinterpreted as false in YAML parsers that followed the older YAML 1.1 specification. This is the "Norway problem." In YAML 1.2 (published 2009), the boolean coercion was tightened to only recognize true and false, not yes/no/on/off, but many parsers including Ruby's Psych (before Ruby 3.1) and PyYAML still default to YAML 1.1 behavior. Unquoted strings in YAML that could be misread as booleans, nulls, or numbers should be explicitly quoted.
Beyond the type coercion issue, YAML's indentation sensitivity is its primary operational challenge. A single space in the wrong place — a key indented by 3 spaces instead of 2, a list item missing its leading dash — changes the structure silently or causes a parse error. Unlike JSON where a missing comma or brace causes an obvious syntax error, YAML indentation mistakes can produce valid but semantically wrong output. Converting from JSON (where structure is explicit) to YAML (where structure depends on indentation) is a reliable way to get correctly indented YAML without manually counting spaces.
Read the Full GuidePaste any valid JSON and click Generate YAML Data — the tool converts the JSON structure to properly indented YAML. JSON objects become YAML mappings with key: value pairs on separate lines. JSON arrays become YAML sequences with each item prefixed by a dash and two spaces. Nested objects and arrays are indented by two spaces per nesting level. JSON strings that do not require quoting in YAML are written without quotes. Strings that contain YAML-special characters (colons, hashes, quotes, leading dashes) are quoted automatically to prevent misinterpretation. Type preservation is handled explicitly. JSON true and false become YAML true and false. JSON null becomes YAML null. JSON numbers are written as bare numbers without quotes. String values that look like YAML reserved words — "true", "false", "null", "yes", "no", "on", "off", numbers as strings — are wrapped in quotes in the YAML output to prevent them from being misread as their non-string equivalents by YAML parsers. This quoting behavior is critical: a JSON field "active": "true" (the string "true", not the boolean true) must appear as active: "true" in YAML, not active: true, to preserve the string type. The output is valid YAML 1.2 that parses correctly in all major YAML parsers. The Schema button on the tool lets you optionally view or generate a JSON Schema representation of the input data alongside the YAML output — useful if you need to document the data structure being converted. Copy the YAML output and use it directly in Kubernetes resource manifests, Docker Compose files, GitHub Actions workflow files, Ansible inventory files, Helm chart values files, or any other YAML configuration that accepts the same data structure as your JSON input.
1. Paste your JSON into the Input JSON field — this can be a complete JSON object, a JSON array, or any fragment of valid JSON. The JSON can come from any source: a kubectl get -o json output, an API response you want to use as a configuration template, a Terraform output, or a manually written JSON structure you want to convert to the YAML format your tooling expects. Click Load Example to see a sample conversion before using your own data.
2. Click Generate YAML Data — the tool parses the JSON and outputs the equivalent YAML with consistent 2-space indentation, proper sequence formatting for arrays, and quoted strings for any values that would be misread by YAML parsers. The conversion is instant for any size input.
3. Review the generated YAML output — check the indentation of nested objects and verify that the structure matches what you expected. Pay specific attention to any string values that should stay as strings but look like booleans or numbers — they should appear quoted (active: "true" not active: true). If you see a value without quotes that should be a string, the JSON input was correctly typed and the YAML output is correct.
4. Optionally click Schema to see a JSON Schema representation of the data structure — useful for documentation or for validating future JSON inputs against the same structure.
5. Copy the YAML output and use it in your target configuration file — paste it into a Kubernetes manifest .yaml file, a docker-compose.yml, a .github/workflows/*.yml GitHub Actions workflow, an Ansible playbook, a Helm values.yaml, or any other YAML configuration. If the target format has a specific top-level structure requirement (like a Kubernetes apiVersion and kind), add those surrounding fields in the YAML file after pasting the converted content.
The most common scenario is Kubernetes. Kubernetes accepts both JSON and YAML for its resource manifests, but kubectl and the entire Kubernetes ecosystem is written around YAML as the canonical human-facing format. The Kubernetes API server itself communicates in JSON over HTTP — when you run kubectl apply -f deployment.yaml, kubectl converts your YAML to JSON before sending it to the API server. But the documentation, the community examples, the Helm chart templates, the kubectl output — it is all YAML. If you have an existing service configuration as JSON (from a program that generated it, from a kubectl get -o json command, from a Terraform output) and need it as a Kubernetes YAML manifest, this conversion is the bridge. GitHub Actions is another concrete case. Workflow files must be YAML — GitHub does not accept JSON workflow definitions. If you generate a workflow configuration programmatically as JSON (from a configuration management system, a workflow generator tool, or a custom build pipeline), you need it converted to YAML before it can be used as a .github/workflows/deploy.yml file. The same applies to Docker Compose, which accepts only YAML for docker-compose.yml, and to GitLab CI .gitlab-ci.yml, CircleCI config.yml, and most other CI/CD pipeline definitions. The reverse scenario — why stay in JSON — is worth acknowledging. JSON is better than YAML when the data will be processed by a program rather than read by a human: REST API payloads, database storage, message queue messages, inter-service communication. JSON has no indentation sensitivity, no type coercion surprises, explicit quoting, and unambiguous parsing. The choice of YAML versus JSON should follow the consumer: if a human or a tool that expects YAML will read it (Kubernetes, Docker, GitHub Actions), convert to YAML. If a program will parse it as data, JSON is usually the right format to stay in.
Correct indentation — generates consistently 2-space-indented YAML so every nesting level is syntactically correct without manually counting spaces
Type-safe conversion — JSON booleans become YAML booleans strings stay as strings and numbers stay as numbers with automatic quoting for string values that would be misread as other types by YAML parsers
Kubernetes and Docker compatible — the generated YAML follows YAML 1.2 conventions and parses correctly in kubectl docker-compose Helm Ansible and GitHub Actions
Array formatting with dashes — JSON arrays become YAML sequences with the correct dash-and-space prefix for each item including arrays of objects
String quoting for special characters — strings containing colons hashes leading dashes or YAML reserved words are automatically quoted to prevent parser misinterpretation
Schema view option — the Schema button shows a JSON Schema representation of the input structure alongside the YAML output for documentation purposes
100% browser-based — your JSON data including Kubernetes manifests Docker configs and CI/CD workflow definitions never leaves your machine
Instant conversion — all parsing and YAML generation runs in your browser with no server round-trip for any size input
Converting kubectl get -o json output to YAML format for use as a Kubernetes manifest template
Converting JSON configuration files to YAML for tools that only accept YAML such as GitHub Actions Docker Compose and Helm
Converting programmatically generated JSON workflow definitions to YAML for CI/CD pipeline files
Converting Terraform output JSON to YAML for use in Kubernetes resource specs or Ansible variables
Converting API response JSON to YAML for use as fixture or test configuration files
Translating JSON-format service configuration to YAML for Docker Compose service definitions
Converting environment variable JSON objects to YAML format for Kubernetes ConfigMap data sections
Learning YAML syntax by converting familiar JSON structures and seeing the equivalent YAML representation
Example Input
{
"name": "learnhubly-api",
"replicas": 3,
"image": "priya/learnhubly:v2.1.0",
"port": 8080,
"env": [
{"name": "NODE_ENV", "value": "production"},
{"name": "LOG_LEVEL", "value": "info"}
],
"resources": {
"cpu": "250m",
"memory": "512Mi"
},
"enabled": true
}Example Output
name: learnhubly-api
replicas: 3
image: priya/learnhubly:v2.1.0
port: 8080
env:
- name: NODE_ENV
value: production
- name: LOG_LEVEL
value: info
resources:
cpu: 250m
memory: 512Mi
enabled: true
# Note: "250m" and "512Mi" are unquoted because they are valid YAML strings.
# "true" here is boolean true (from JSON boolean true) — correct.
# If "enabled" were the string "true", it would appear as enabled: "true"Invalid JSON Input: The tool requires valid JSON before converting to YAML. Common issues that prevent conversion: unquoted keys (YAML uses unquoted keys but JSON requires them quoted), trailing commas after the last item in an object or array, single-quoted strings (JSON requires double quotes), or JavaScript-style comments. Use the JSON Formatter and Validator tool first to fix any syntax errors.
Indentation Errors When Manually Editing YAML After Conversion: The generated YAML uses consistent 2-space indentation. If you copy the YAML and then manually edit it — adding a new field, inserting a list item, removing a nested block — accidental indentation changes break the YAML structure. YAML parsers treat incorrectly indented keys as belonging to the wrong parent object or as a parse error. After manual edits, validate the YAML with a YAML linter before using it in Kubernetes, Docker, or a CI/CD pipeline. A single 3-space indent where 2 spaces are expected silently moves a field to the wrong parent.
String Values Containing Colons Parsed as Mappings: In YAML, a colon followed by a space (': ') is the key-value separator. If a string value contains a colon and a space — a URL like https://example.com or a message like 'Error: file not found' — YAML parsers misread it as a mapping unless the string is quoted. The tool automatically quotes strings that contain colon-space sequences. If you see unexpected YAML parse errors in a value that contains a URL or error message, check whether the string is properly quoted in the output.
Boolean and Null String Values Not Quoted: The JSON string 'true' and the JSON boolean true produce different YAML output intentionally — the string produces quoted 'true' and the boolean produces unquoted true. If your YAML consumer receives the wrong type, check the original JSON type. In JSON, 'active': true is a boolean and 'active': 'true' is a string. The conversion preserves this distinction — verify your JSON has the intended type before converting.
Multiline Strings Losing Formatting: JSON does not support multiline strings — a newline in a JSON string value must be represented as the escape sequence \n. When the tool converts these to YAML, escaped newlines in JSON strings become single-line string values in YAML. For YAML's block scalar syntax (the | and > block styles that allow literal multiline strings), the content must be written directly in YAML — it cannot be derived from a JSON \n escape sequence in a single-line string. If your JSON contains values with \n that should become YAML multiline blocks, add the block scalar syntax manually after conversion.
Expecting YAML comments to be generated from the JSON structure
Fix: JSON does not support comments — the JSON format has no comment syntax. When you convert JSON to YAML, the output contains no comments because there were no comments in the source. YAML supports comments using # and they are the main readability advantage YAML has over JSON for configuration files, but they must be added manually after conversion. After converting, add # comments to explain the purpose of configuration sections, non-obvious values (why memory is 512Mi instead of 1Gi), and any context a reader needs to understand the configuration. The conversion gives you the structure; the documentation is still your job.
Using the generated YAML directly in Kubernetes without adding the required apiVersion, kind, and metadata fields
Fix: Kubernetes resources require specific top-level fields that are part of the Kubernetes API structure, not part of your application data: apiVersion (like apps/v1 or v1), kind (Deployment, Service, ConfigMap, etc.), and metadata with at least a name. Converting a JSON object that represents the spec section of a Deployment gives you a YAML block that is not a valid Kubernetes manifest until wrapped with these required fields. After converting your spec data, add the Kubernetes wrapper: apiVersion: apps/v1, kind: Deployment, metadata: { name: your-app }, spec: { ... converted content ... }. The converted YAML goes inside the appropriate spec or data section of the manifest.
Not testing the generated YAML before using it in CI/CD pipelines or production deployments
Fix: YAML parsing behavior varies subtly between parsers, and a YAML file that looks correct can fail at runtime. Before using generated YAML: validate Kubernetes manifests with kubectl apply --dry-run=client -f manifest.yaml, validate Docker Compose files with docker-compose config, validate GitHub Actions workflows by pushing to a test branch and checking the Actions tab for parse errors, validate Ansible playbooks with ansible-playbook --syntax-check playbook.yml. These dry-run checks catch YAML structure problems, missing required fields, and type errors before they cause deployment failures.
Converting a full Kubernetes resource JSON to YAML without understanding that kubectl get -o json includes server-generated fields
Fix: Running kubectl get deployment/my-app -o json and converting the output to YAML gives you the full representation of the resource as stored in Kubernetes, including server-generated metadata fields: resourceVersion, uid, creationTimestamp, managedFields, and status. If you use this as a manifest template and apply it, Kubernetes may reject it or behave unexpectedly because those fields are managed by Kubernetes, not user-defined. Before using a kubectl get -o json output as a manifest, remove or clean the server-side fields. Use kubectl get --export (deprecated) or manually remove resourceVersion, uid, creationTimestamp, managedFields, and the entire status section from the converted YAML.
Assuming YAML anchors and aliases can be created from JSON
Fix: YAML has a feature called anchors (&anchor-name) and aliases (*anchor-name) that allow you to define a value once and reference it multiple times in the same document — like variables in a config file. Docker Compose uses this extensively for sharing service configuration. JSON has no equivalent — you cannot reference the same value in two places in JSON. When you convert JSON to YAML, the output will have duplicate values wherever the JSON had duplicate values — there is no automatic deduplication into anchors. If you want anchors in your YAML, add them manually after conversion. Find repeated blocks, define an anchor on the first occurrence, and replace subsequent occurrences with alias references.
JSON Cheatsheet
Interactive reference guide for valid JSON syntax, data types, parsing/stringifying methods, schema validation rules, and language integrations.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
SQL Cheatsheet
Complete guide to SQL statements including SELECT queries, WHERE filters, aggregate functions, JOIN types, and DDL commands.
Does it support comments?
No, and by design. JSON does not have a comment syntax — JSON data cannot contain comments. The converter produces YAML that faithfully represents the JSON data, and since JSON has no comments to convert, the YAML output has no comments either. YAML supports # comments and they are a significant readability benefit over JSON for configuration files, but they must be added manually. After converting, add comments to explain non-obvious values, document the purpose of configuration sections, and note any constraints or version requirements. The converter gives you the correctly structured YAML; documentation is yours to add.
What is the Norway problem in YAML?
In YAML 1.1 (used by many parsers before YAML 1.2 was widely adopted), the following values were automatically converted to boolean true: yes, Yes, YES, true, True, TRUE, on, On, ON. And to boolean false: no, No, NO, false, False, FALSE, off, Off, OFF. The two-letter ISO 3166 country code for Norway is NO — when a YAML file listed country codes as unquoted strings, NO was parsed as boolean false instead of the string 'NO'. This is the Norway problem, named after the country that discovered it. YAML 1.2 restricts boolean recognition to only true and false, but many widely-used parsers (PyYAML, Ruby's Psych before 3.1, Go's gopkg.in/yaml.v2) still use YAML 1.1 semantics. This tool quotes string values that match YAML 1.1 boolean patterns to prevent misinterpretation.
Is the generated YAML compatible with Kubernetes?
Yes. The tool generates YAML 1.2 with 2-space indentation, which is what kubectl and the Kubernetes API accept. Kubernetes resource manifests written in YAML are converted to JSON by kubectl before being sent to the API server, so the YAML just needs to parse correctly and represent the right data structure. Note that converting a JSON object to YAML gives you the data content — a complete Kubernetes manifest also needs the top-level apiVersion, kind, and metadata fields that are part of the Kubernetes resource structure. Add those wrapper fields after converting your application configuration data.
Can I convert YAML back to JSON?
Yes — use the YAML Formatter and Validator tool on LearnHubly which includes bidirectional YAML-to-JSON conversion. This is useful when you have a YAML configuration file and need the JSON representation for an API call, for processing with jq, or for use in a context that only accepts JSON. YAML is a superset of JSON, so the conversion is always possible in both directions, though YAML-specific features like comments and anchors have no JSON equivalent and are dropped during YAML-to-JSON conversion.
How does YAML handle different data types compared to JSON?
JSON has six data types: string, number, boolean (true/false), null, object, and array. YAML has the same underlying types plus additional scalar types in YAML 1.1 like timestamps, binary data, and ordered maps. For conversion purposes, the mapping is direct: JSON strings become YAML strings (usually unquoted unless the value could be misread), JSON numbers become YAML numbers, JSON true/false become YAML true/false, JSON null becomes YAML null (~ is also valid YAML for null), JSON objects become YAML mappings, and JSON arrays become YAML sequences. The main type preservation concern is strings that look like other types — the string 'true', the string '123', the string 'null' — which the converter quotes automatically.
What is YAML's block scalar syntax and can I generate it from JSON?
YAML has two block scalar styles for multiline strings. The literal block scalar (|) preserves newlines exactly: the string spans multiple lines and each newline in the YAML file becomes a newline in the parsed string. The folded block scalar (>) folds newlines into spaces for flowing text paragraphs. These styles make long strings readable in YAML configuration files without backslash escapes. JSON represents newlines in strings as \n escape sequences in a single-line string value. The converter produces YAML with \n preserved as an escape (not a block scalar) because automatically choosing between | and > depends on context and intent. After conversion, if you have a string value with \n escapes that should be a block scalar, manually replace the single-line value with the | or > block style.
Does YAML support everything JSON supports?
Yes — YAML is a superset of JSON in the sense that every JSON document is valid YAML. The converse is not true: YAML has features JSON does not have (comments, anchors, aliases, block scalars, multiple documents in one file). For simple data interchange — the typical API response structure with objects, arrays, strings, numbers, booleans, and null — the data models are identical and conversion is lossless. The only theoretical loss is precision in number representation: JSON allows arbitrarily large numbers but YAML parsers may interpret very large numbers as floats with precision loss. For practical configuration data, this is never an issue.
Why does Kubernetes use YAML instead of JSON for manifests?
Kubernetes accepts both — the API server communicates in JSON, and you can use kubectl apply -f manifest.json just as easily as manifest.yaml. But the Kubernetes community standardized on YAML for manifests primarily because YAML supports comments and is more compact and readable for the deeply nested structures that Kubernetes resources often have. A Kubernetes Deployment manifest with resource limits, environment variables, volume mounts, and health checks is significantly more readable in YAML than in JSON. Helm, the Kubernetes package manager, uses YAML templates and would be significantly harder to read and write as JSON. The ecosystem built around YAML, so YAML became the de facto standard even though JSON is technically equivalent.
Data Conversion Best Practices for Developers – Complete Guide 2026
Data Conversion Best Practices for Developers in 2026. In-depth guide covering JSON, XML, CSV, Markdown conversions, data integrity, security risks, performance optimization, and expert strategies from a Principal Software Engineer with 15+ years experience.
What is JSON? How to Format, Validate & Use It (Complete Guide 2026)
What is JSON? How to Format, Validate & Use It (Complete Guide 2026). In-depth explanation of JSON syntax, real-world use cases, formatting best practices, common mistakes, advantages, disadvantages, and expert tips from a Principal Software Engineer with 15+ years experience.
How to validate JSON online (step-by-step guide)
Invalid JSON can break your application. Follow this guide to quickly validate and fix your JSON data.
Recent Activity
No recent activity