Why does the output quote some strings but not others?

YAML infers a scalar's type from its literal, unquoted text. A string that happens to look like something else, a reserved word like true, false, null, yes, or off, a number like 1.0 or 007, or a string starting with a character that has special meaning in YAML syntax (-, ?, :, #, &, *, and a few others), would get silently read back as a boolean, a number, or a syntax error instead of the original string. The converter checks every string value against those rules before deciding whether to emit it as-is or wrap it in double quotes, and only quotes the ones that actually need it. This keeps the output as clean as idiomatic hand-written YAML, quoting only where quoting changes the meaning, rather than defensively quoting everything, which is a common but noisier alternative.

Can I convert Kubernetes JSON manifests to YAML?

Yes. kubectl can output any resource as JSON with kubectl get pod x -o json, and this tool converts that directly into the block-style YAML most Kubernetes manifests are actually written and committed in. This is a common workflow because some tooling (client libraries, jq-based scripts, API responses) is easiest to work with as JSON, but the manifest a human eventually reviews or commits to a repo should be YAML for readability. One thing to check afterward: key order in the converted YAML follows the JSON's own key order, which for kubectl's JSON output generally matches the conventional apiVersion / kind / metadata / spec ordering. Still worth a quick diff against a known-good manifest if you're pasting into a review-sensitive file.

Does this tool support YAML anchors and references?

No. It always produces plain, fully expanded block-style YAML with no anchors (&name) or aliases (*name), since JSON itself has no concept of "this value is a reference to that other value", every JSON value is already fully expanded by the time it's parsed. If your source data has repeated substructures, they'll appear repeated in full in the YAML output too, rather than being factored out into an anchor and reused with aliases. If you need anchors for readability or to reduce duplication in a hand-maintained YAML file, that's a manual editing step to do after conversion, not something this tool can infer from JSON alone.

Is my JSON data uploaded to a server?

No. Conversion happens entirely in your browser. The JSON gets parsed with JSON.parse() and then walked recursively to build the YAML string, all in client-side JavaScript with no backend call involved. Nothing about your input, the resulting YAML, or the fact that you ran a conversion gets sent over the network, logged, or stored. This matters because YAML conversion is often used on Kubernetes manifests, CI configs, and other files that can contain internal hostnames, service names, or environment-specific values you wouldn't want leaving your machine. Watch your browser's network panel while converting if you want to confirm it yourself, there's no request tied to the data you pasted.

How does this differ from the JSON to XML converter?

Both re-serialize the same parsed JSON value into a different text format, but they target different consumers. YAML is the format modern DevOps tooling favors, Kubernetes manifests, GitHub Actions and GitLab CI configs, docker-compose files, because indentation-based block style is compact and comfortable to hand-edit, and it supports comments, which JSON doesn't. XML is what older enterprise systems, SOAP services, and some legacy build tools expect, and it supports constructs like attributes and namespaces that YAML has no equivalent for. If you're converting for a DevOps config file or something a person will hand-edit afterward, use this tool. If you're feeding a system that specifically requires XML, use the JSON to XML converter instead.

What happens when the top-level JSON value is an array or a plain scalar?

A top-level array renders as a plain dash-prefixed YAML sequence with no enclosing key, so [{"id":1},{"id":2}] becomes two lines starting with "- id: 1" and "- id: 2" rather than being nested under a synthetic root key. A top-level scalar, a bare string, number, boolean, or null, renders as that single scalar's YAML form with no surrounding structure at all, applying the same quoting rules used everywhere else. Converting the JSON string "yes" alone produces the quoted line "yes" (with quotes) rather than an unquoted yes that would be read back as a boolean. Both are valid YAML documents on their own. A YAML file doesn't need a top-level mapping the way some tools assume.

Why are 'yes', 'no', 'on', and 'off' quoted as strings when they're clearly not booleans in my data?

Those four words are booleans under the older YAML 1.1 specification, even though YAML 1.2 narrowed the boolean literals down to just true and false. This converter quotes the YAML 1.1 set defensively (yes, no, on, off, and their case variants, alongside true, false, null, and ~), because a lot of real-world YAML tooling, including PyYAML's default loader and older versions of Kubernetes tooling, still parses YAML with 1.1-style boolean inference even when the document doesn't declare a version. Quoting these words is the safer default precisely because you can't always know which parser will read the output. An unquoted "on" is a boolean in some parsers and a string in others, and quoting it removes the ambiguity entirely regardless of which one processes your file.

Does the converter preserve the key order from the source JSON?

Yes. Object keys get emitted in the same order JavaScript's own iteration returns them in, which for JSON.parse() output means the order the keys first appeared in the source document. There's one caveat inherited from JavaScript itself: keys that look like non-negative integers, like "0" or "1", are always iterated first and in numeric order, ahead of any string keys, regardless of where they appeared in the original text. For the vast majority of real-world JSON, object keys aren't integer-like strings, so the output order matches the input order exactly. This matters for anything where a human will diff or review the converted YAML against a reference manifest, since an unexpected reordering would otherwise look like an unrelated change.

JSON to YAML Converter - Convert JSON Online

Overview

Introduction

YAML has become the default format for Kubernetes manifests, CI pipelines, and countless config files, but many tools still emit JSON. This converter turns that JSON into clean, properly quoted block-style YAML you can drop straight into a config file.

It exists because that gap shows up constantly in DevOps workflows. `kubectl get pod x -o json` gives you JSON, but the manifest you're actually going to commit is YAML. Converting by hand means remembering YAML's quoting rules for reserved words and special leading characters, which is exactly the kind of detail that's easy to get subtly wrong under time pressure.

What Is JSON to YAML Converter?

A JSON-to-YAML converter re-serializes a JSON value using YAML's block style: two-space indentation, dash-prefixed list items, and colon-separated key-value pairs, quoting only the scalars that would otherwise be ambiguous.

YAML is a strict superset of JSON in terms of what it can represent, but idiomatic YAML avoids JSON's flow-style braces and brackets in favor of indentation-based block style, since that's what makes hand-edited YAML readable. This tool targets that idiomatic block style instead of simply re-indenting flow-style output, so the result looks like YAML a person would actually write.

How JSON to YAML Converter Works

The tool parses your JSON, then walks the resulting structure recursively, emitting nested objects as indented key blocks and arrays as dash-prefixed lists. Strings stay unquoted unless they collide with a YAML reserved word (true, false, null, ~), start with a character that has special meaning (-, ?, :, #, etc.), or could be misread as a number.

That selective quoting matters because YAML's type inference is based on a string's literal form. An unquoted `yes` or `on` is parsed as a boolean under YAML 1.1, and an unquoted `3.0` is parsed as a number, not a string. The converter checks each scalar against those rules before deciding whether to wrap it in quotes, so a JSON string value round-trips back to a string when the YAML is parsed instead of silently changing type.

When To Use JSON to YAML Converter

Use it when a tool gives you JSON but the file you need to write is YAML, for example converting a JSON API response into a Kubernetes ConfigMap, a GitHub Actions step, or a docker-compose fragment.

It's also useful for producing readable YAML documentation from a JSON example. Block-style YAML with clean quoting is generally easier for a person to scan than the equivalent JSON, even outside of any specific tool that requires YAML as input.

Often used alongside JSON to XML Converter, JSON to CSV Converter and JSON Formatter & Beautifier.

Features

Advantages

Produces clean, human-readable block-style YAML rather than YAML's less common flow style.
Automatically quotes only the strings that actually need it, keeping output tidy.
Handles arbitrarily nested objects and arrays.
No server round-trip, which matters for config files that may contain secrets or internal hostnames.

Limitations

Does not generate YAML anchors, aliases, or multi-document separators.
Comments are not preserved or generated, since JSON has no comment concept to carry over.
Very large numbers or numbers with trailing zeros may render slightly differently than the original source formatting, since JSON itself doesn't preserve numeric formatting.

YAML vs. JSON: When to Use Each

YAML vs. JSON: When to Use Each
	YAML	JSON
Required by	Kubernetes, GitHub Actions, most CI configs	REST APIs, JavaScript data
Supports comments	Yes	No
Whitespace-sensitive syntax	Yes, indentation defines structure	No, braces and brackets define structure
Best for	Hand-edited config and manifest files	Programmatic data exchange

Examples

Simple config object

Input

{"name":"api","replicas":3,"env":["prod","staging"]}

Output

name: api
replicas: 3
env:
  - prod
  - staging

Scalars become key: value lines, arrays become dash-prefixed block lists.

Nested object with a nested array

Input

{"user":{"name":"Ada","age":30,"roles":["admin","editor"]}}

Output

user:
  name: Ada
  age: 30
  roles:
    - admin
    - editor

A nested object becomes an indented block under its key, with no colon or value on the parent line. The nested array indents one further level as a dash-prefixed list.

Array of objects

Input

{"users":[{"id":1,"name":"Ada"},{"id":2,"name":"Bo"}]}

Output

users:
  - id: 1
    name: Ada
  - id: 2
    name: Bo

Each object in the array becomes a dash-prefixed block. The object's first key shares the dash's line, and remaining keys align underneath it.

Strings that need quoting

Input

{"status":"yes","version":"1.0","flag":"true","note":"hello: world","id":"007"}

Output

status: "yes"
version: "1.0"
flag: "true"
note: "hello: world"
id: "007"

Every value here is a JSON string, but each would be misread as something else if left unquoted: "yes"/"true" as booleans, "1.0"/"007" as numbers, and "hello: world" as a nested key because of the embedded colon. The converter quotes exactly these five and leaves an ordinary string like "hello" unquoted.

Empty array and empty object

Input

{"a":{},"b":[]}

Output

a: {}
b: []

Empty objects and arrays fall back to YAML's compact flow-style {} and [] on the same line as the key, rather than an indented block with nothing in it.

Invalid JSON input

Invalid input

{"a": 1,}

Parser error

SyntaxError: Expected double-quoted property name in JSON at position 8 (line 1 column 9)

The converter parses your input with JSON.parse() before emitting any YAML, so a trailing comma or other syntax error gets reported immediately as a parse error rather than producing partial or guessed-at output.

Corrected version

{"a": 1}

Best Practices & Notes

Best Practices

Review quoted strings after conversion: if a value looks like it shouldn't be quoted, check whether it collides with a YAML reserved word.
For Kubernetes manifests, diff the converted YAML against a known-good example to confirm key ordering and structure match expectations.
Keep a JSON source of truth and regenerate YAML at build time rather than hand-editing generated YAML.
If the converted YAML feeds a tool you don't control the parser version of, treat the YAML 1.1 reserved-word quoting as a feature, not noise: it protects against older loaders that still read yes/no/on/off as booleans.
For a top-level JSON array, expect a bare dash-prefixed sequence with no wrapping key. Add an enclosing object in the JSON first if your target file needs a named top-level key.
When converting config that will be committed to version control, run the output through a YAML linter once, since this tool guarantees syntactic correctness but not conformance to a specific team's style rules (indent width, quote style, key casing).

Developer Notes

The quoting logic checks a value against several independent rules before deciding whether it needs quotes: YAML 1.1 reserved words (true/false/null/yes/no/on/off and their case variants, plus ~), a leading character with special meaning in YAML syntax (-, ?, :, ,, brackets, braces, #, &, *, !, |, >, quote characters, %, @, or a backtick), leading or trailing whitespace, an embedded colon or hash (which could be misread as a key separator or a comment), and strings that look like a decimal, hex, or octal number. Any string matching one of those gets quoted using JSON.stringify, which both wraps it in double quotes and guarantees any special characters inside it (backslashes, embedded quotes) are escaped validly, instead of hand-rolling YAML's own quoting escape rules. Object keys go through the identical check, so a key like "yes" or one containing a colon gets quoted exactly the same way a value would be. Arrays and objects nested inside array items are handled by re-indenting the nested block and merging its first line onto the dash, which is why an object as an array item renders as "- key: value" with subsequent keys aligned underneath, rather than the dash sitting on its own line above the block.

JSON to YAML Converter Use Cases

Converting a JSON API response into a Kubernetes manifest fragment
Turning JSON config into a GitHub Actions or GitLab CI YAML step
Migrating a JSON-based settings file to a YAML-based tool
Producing readable YAML documentation from a JSON example
Converting the JSON output of a CLI tool (kubectl, aws, gcloud) into YAML for a manifest or IaC template
Spot-checking how a specific JSON value would be quoted in YAML before writing it by hand into an existing manifest

Common Mistakes

Assuming the output includes YAML anchors or references. It always produces flat, expanded structures.
Not noticing when a string like "yes" or "on" gets quoted. That's intentional, since unquoted it would be read as a boolean in YAML.
Pasting JSON with comments (JSONC), which fails to parse since it isn't valid JSON.
Assuming a top-level JSON array converts under a synthetic key; it renders as a bare sequence with no wrapping key at all.
Expecting the converted YAML to carry over comments from wherever the JSON originally came from. JSON has no comment syntax, so there's nothing for the converter to preserve.

Tips

If your target tool expects a specific key order, check the converted YAML. Key order always follows the source JSON's insertion order, with one caveat: integer-like keys ("0", "1") are always ordered first, ahead of any string keys, following standard JavaScript object key iteration.
For deeply nested configs, format the JSON first so it's easier to sanity-check before converting.
If you're not sure whether a value will need quoting, convert it on its own first (as a single-key object) to check, rather than scanning a large converted document for one quoted string.
Empty objects and arrays render as compact {} and [] rather than an indented block. That's expected and matches how most hand-written YAML represents "nothing here".

JSON to YAML Converter

Overview

Introduction

What Is JSON to YAML Converter?

How JSON to YAML Converter Works

When To Use JSON to YAML Converter

Features

Advantages

Limitations

YAML vs. JSON: When to Use Each

Examples

Simple config object

Nested object with a nested array

Array of objects

Strings that need quoting

Empty array and empty object

Invalid JSON input

Best Practices & Notes

Best Practices

Developer Notes

JSON to YAML Converter Use Cases

Common Mistakes

Tips

References

Frequently Asked Questions