JSON to YAML Converter

Why a JSON String Sometimes Gets Quoted in the YAML Output

YAML's scalar syntax is ambiguous in ways JSON's isn't: an unquoted yes, null, or a bare number-looking string can be silently parsed as a boolean, null, or number by a YAML reader instead of the string you meant. This converter guards against that by auto-quoting any string that contains a colon, hash, or hyphen, starts or ends with whitespace, starts with a digit, or spells out true, false, or null literally. So the JSON value "1.0" or "port: 8080" comes out wrapped in quotes in the YAML even though you didn't ask for "Quote All Strings" — that's the converter protecting you from a downstream parser misreading the type.

This matters because YAML is indentation-sensitive in a way JSON simply is not — JSON's braces and commas make structure explicit regardless of whitespace, while a YAML parser infers nesting purely from how many spaces precede a line. Mixing tabs and spaces, or pasting YAML that got re-indented by an editor, is one of the most common real-world YAML failures. The "Indent Size" option here controls only what this tool generates; if you're hand-editing the result afterward, stay consistent with spaces (tabs are not valid for indentation in YAML at all).

What "Flow Style" Actually Changes

Enabling Use Flow Style for Arrays only affects arrays nested inside another structure — it renders them JSON-like as [1, 2, 3] on one line instead of one block-style - item per line. A top-level array (when your entire input is an array rather than an object) always renders in block style regardless of this setting, since flow style only kicks in below the root. If you're generating a Kubernetes manifest or Ansible playbook — formats where reviewers expect the conventional dash-per-line list — leave flow style off; it's more useful for compact config snippets or CI matrix definitions where a short inline list is easier to scan.

One-way street to be aware of: YAML supports features JSON has no way to express, including inline comments (# like this), anchors/aliases for reusing a block by reference, and multiple documents separated by --- in a single file. Because this tool starts from JSON, none of those YAML-only features can appear in the output — you're getting a faithful data conversion, not a hand-authored YAML file with documentation baked in. If a target file needs comments explaining each setting, you'll still need to add those by hand after converting.

Where This Fits in a DevOps Workflow

A common real scenario: an API or internal tool emits JSON, but the config format your deployment pipeline consumes — a Kubernetes manifest, a Docker Compose file, a GitHub Actions workflow, an Ansible playbook — is YAML. Converting once to get the structure right, then hand-tuning comments and anchors afterward, is usually faster than writing the YAML from scratch. It's also useful in reverse-engineering: paste the JSON output of kubectl get pod -o json to get a YAML skeleton close to what you'd write by hand for a new manifest.

Frequently Asked Questions