Online JSON to YAML Converter

1. Bidirectional convert

Large integers outside JavaScript safe integer range are written as digit strings on the JSON→YAML path so digits are not silently rounded in the YAML text. Coming back YAML→JSON still goes through js-yaml Number semantics for ordinary numbers — treat round-trips of huge IDs as a verification step, not a guarantee. Nested objects and arrays are preserved as structure; this is not a string-escape toy that only wraps quotes.

1. Pick JSON→YAML or YAML→JSON.
2. Paste the source document. For JSON→YAML, invalid JSON fails fast; for YAML→JSON, parse errors often include line and column with indentation hints in the panel.
3. Copy the result, then validate in the system that will actually consume it — looking correct in the converter is not the same as passing the deployer.

2. YAML footguns that break production configs

Unquoted yes, no, on, off, true, and false can become booleans. Country codes, feature flags, and version strings that look like numbers need quotes. Indentation must be spaces; tabs commonly explode parsers. Anchors and aliases may expand when you pass through JSON and back. Comments never survive YAML→JSON because JSON has no comment syntax — move operational notes to a README or keep them only in the YAML source of truth.

• Quote any scalar that is not unambiguously a number or boolean.
• Normalize to two spaces before pasting if your editor mixed tabs.
• If kubectl rejects the result, fix indentation near the reported line before changing data values.
• Duplicate keys are a smell — resolve which value you meant before converting.

3. Text diff vs semantic sameness

Key order, quoting style, and folded vs literal block scalars can produce huge diffs with identical meaning. Compare objects after parse when reviewing changes. Failure sample: converting pretty JSON to YAML and back yields different whitespace but the same tree — do not treat that as a data regression. Failure sample: a YAML comment explaining a port mapping vanishes after JSON round-trip; the port value remains, the explanation does not. Failure sample: Norway country code NO without quotes becomes boolean false in some YAML 1.1 interpreters — always quote it.

4. Choosing a format as the source of truth

Prefer YAML when humans edit often, need comments, or rely on anchors. Prefer JSON when APIs and strict parsers are the consumers. If both sides exist, designate one source of truth and generate the other — dual editing drifts. This page is a translator, not a merge tool for conflicting edits, and not a Kubernetes schema validator.

5. Troubleshooting parse failures

Structured conversion here does not execute custom YAML tags or language-specific deserializers. Still treat pasted manifests from email or tickets as untrusted input: validate schema and apply in a dry-run environment before production. Secrets in env blocks should be redacted before you paste into shared tickets.

1. For messy JSON, run a formatter first so brace errors are easier to see, then convert.
2. Read the line and column from the error panel; check colon spacing and list dashes on that line.
3. Duplicate keys and tab indentation often get dedicated hints in the UI — follow those before rewriting the whole file.
4. If only one nested block fails, paste that block alone to isolate the syntax issue, then reassemble.

6. Safety, privacy, and handover

Configs frequently embed tokens. Local conversion reduces upload risk, but screenshots, shared screen sessions, and downloaded copies still leak. After a successful convert, keep a short note of direction and known non-round-trip items (comments, anchors, huge integers) for the next person who touches the file. Prefer checking the converted manifest with the same CLI your pipeline uses so local success matches CI.