JSON to YAML Converter

1. Paste JSON into the left pane or use Open file. The YAML appears as you type; Ctrl/⌘+Enter converts immediately.
2. Pick an indent of 2 or 4 spaces. Two is the convention for Kubernetes and GitHub Actions.
3. Set Wrap to control long strings. At 80 columns, long text is written as a folded >- block; choose No wrapping to keep each value on one line.
4. Choose a quote style. "When needed" quotes only strings that would otherwise change meaning; Always double quotes every string, which some teams prefer for consistency.
5. Turn on Sort keys for stable, diff-friendly output, then copy or download the .yaml file.

⇄ YAML to JSON opens the YAML to JSON converter with your result loaded, which is a quick way to confirm the round trip.

A common workflow is exporting a live object and turning it into a manifest you can commit:

kubectl get deployment web -o json > web.json
# paste web.json here, then delete status, metadata.uid,
# metadata.resourceVersion and other server-managed fields

kubectl accepts JSON manifests as well as YAML, so the conversion is about readability rather than compatibility. The same goes for API responses you want to turn into Helm values.yaml defaults, or JSON emitted by Terraform or a script that has to become an Ansible variables file.

CI systems are stricter. GitHub Actions reads workflows only from .yml or .yaml files in .github/workflows, and GitLab reads .gitlab-ci.yml. If you generate pipeline definitions with a script, emitting JSON and converting it is often simpler than templating YAML text by hand, because you never have to worry about indentation inside string concatenation.

YAML guesses the type of an unquoted value, so some JSON strings would turn into something else if they were written bare. The converter quotes these for you; this is what to watch for when you edit the result by hand:

enabled: 'yes'        # bare yes/no/on/off/y/n are booleans in YAML 1.1 parsers
zip: '02134'          # leading zero: bare 02134 is a number (octal in YAML 1.1)
version: '1.10'       # bare 1.10 is the float 1.1
time: '12:30'         # bare 12:30 is the integer 750 in YAML 1.1 (base 60)
greeting: 'a: b'      # ": " inside a plain value starts a new mapping
channel: '#general'   # a leading # starts a comment
note: 'x #y'          # " #" ends the value and starts a comment
empty: ''             # a bare empty value is null, not an empty string
nothing: '~'          # ~ is null

The quoting is deliberately conservative. js-yaml follows YAML 1.2, where yes is just a string, but it still quotes YAML 1.1 booleans because the file may later be read by an older parser such as PyYAML. Kubernetes label values and environment variables are a common place where an unquoted on or no causes a type error at apply time.

JSON has no comment syntax, so the YAML you get has no comments either. If you are converting a file that started life as commented YAML, converted to JSON and edited by a tool, the original comments are gone and need to be restored from version control. The same applies to anchors and aliases: the output never uses & or *, so repeated blocks are written out in full. That is longer, but it is what most reviewers and tools expect.

Duplicate keys are another silent loss. RFC 8259 only says object names SHOULD be unique, and JSON.parse keeps the last value, so {"a": 1, "a": 2} becomes a: 2. Run the input through the JSON validator first if you suspect duplicates.