PDFFlare
8 min read

How to Convert JSON to YAML for Kubernetes (and YAML to JSON Back)

You've got a JSON config — maybe an API response, maybe an export from a dashboard — and you need to feed it into kubectl apply, a GitHub Actions workflow, a Docker Compose stack, or a Helm values file. All of those want YAML, not JSON. Or you're going the other direction: a YAML config needs to land in a JS app or hit an API that only speaks JSON.

In this guide you'll learn how to convert JSON to YAML (and YAML back to JSON) using PDFFlare's JSON to YAML converter — plus what carries through the round trip cleanly, what gets lost, and how to handle Kubernetes manifests, GitHub Actions, and Helm values.

Why Convert JSON to YAML?

YAML is the lingua franca of modern infrastructure. JSON is what APIs and JavaScript apps speak. Conversion between them comes up constantly:

  • Kubernetes manifests:kubectl accepts both, but every example, every Helm chart, every operator's docs use YAML. Real teams converge on YAML.
  • GitHub Actions / GitLab CI:CI workflow files are YAML by spec. If you're generating a workflow programmatically, you build JSON and convert.
  • Docker Compose: docker-compose.yml — YAML required.
  • Helm values: values.yaml drives every Helm chart. Custom overrides typically start as JSON exports from a dashboard, then get converted.
  • Ansible playbooks, Serverless framework, CloudFormation: All YAML by default.

Going the other way (YAML → JSON) is just as common: feeding a YAML config to a JS app, sending it as an API body, or processing it with tools like jq that only speak JSON.

How to Convert JSON to YAML (Step by Step)

PDFFlare's converter is bi-directional. Both directions run entirely in your browser via js-yaml — your configs (which often contain secrets) never upload anywhere.

  1. Open PDFFlare's JSON to YAML converter — no signup needed.
  2. Paste your JSON into the input pane. Could be a 10-line snippet or a 5,000-line Kubernetes manifest export.
  3. Click Convert. The output is YAML 1.2 with sensible indentation, ready to paste into kubectl apply -f - or your editor.
  4. Copy or download. Save as config.yaml or pipe directly to kubectl.
  5. To go YAML → JSON: toggle the direction selector, paste your YAML, click Convert. The Swap button moves the output back to the input for round-tripping.

Quick YAML Refresher (For JSON People)

If you know JSON, YAML is mostly intuitive. The key differences:

  • No braces or brackets — indentation defines structure. 2 spaces per level is the de facto standard.
  • No commas — newlines separate items in a sequence or mapping.
  • Strings rarely need quotes. Just write the value. Quote only when the value would be ambiguous (numeric strings, booleans you want as strings, leading whitespace, special chars).
  • Lists use leading dashes. ["a", "b"] in JSON becomes - a\n- b in YAML.
  • Comments start with #— and yes, YAML has them, JSON doesn't. This is one reason teams prefer YAML for human-edited configs.

What's Preserved in the Round Trip

  • Object structure: Mappings with string keys preserve cleanly.
  • Array structure: Sequences round-trip.
  • Scalar values: Strings, numbers, booleans, null. One gotcha: numeric-string values like "42" in JSON become quoted in YAML and round-trip correctly.
  • Nested structure: Arbitrary depth handled.

What's Lost

  • Comments. JSON has no concept of comments, so any YAML comments are stripped on YAML → JSON. They are not re-injected when going JSON → YAML.
  • YAML anchors and aliases. An anchor like &base with subsequent <<: *basemerges is resolved on parse — the JSON output has the resolved values inline, not the anchor reference. Going JSON → YAML doesn't re-create anchors.
  • Custom tags. YAML supports custom tags (!!Foo); the converter handles the standard tag set but custom tags are dropped or stringified.
  • Document separators. YAML files can contain multiple documents separated by ---. The converter handles a single document; for multi-doc YAML, split first.

Kubernetes Manifests: Beyond Basic Conversion

A real Kubernetes workflow involves more than a one-shot conversion. Some patterns worth knowing:

  • Multi-resource manifests: A single YAML file can contain multiple resources separated by ---. If you're generating from JSON, build an array, convert each element to YAML, then join with --- on its own line.
  • ConfigMap data quirk: ConfigMap values are strings — even if the source data is JSON. So a ConfigMap holding a JSON config has it stringified inside the YAML, not nested. Watch for this when round-tripping.
  • Secret base64 encoding:Secret values are base64-encoded in YAML. If you're building from JSON, encode the values yourself before conversion — the converter does not.
  • Helm template-rendered output: Run helm template chart/ to materialize all templates, then convert specific resources to JSON for inspection or diffing.

GitHub Actions Workflow Conversion

GitHub Actions workflows are YAML, but a lot of folks build them programmatically (e.g. generating per-environment workflows, or building reusable matrices). The standard pattern:

  1. Build the workflow shape as a JS or TS object.
  2. JSON.stringify it (or just use the literal).
  3. Run through PDFFlare's converter to get YAML. Note that GitHub Actions has some YAML-specific syntax (${{ }} expressions) that round-trips fine as quoted strings — wrap in quotes in the JSON: "if": "${{ github.event_name == 'push' }}".
  4. Commit the result as .github/workflows/main.yml. GitHub picks it up on next push.

Helm Values: JSON-Friendly Override Pattern

If you're managing Helm releases programmatically, JSON is easier to manipulate than YAML. The pattern:

  1. Maintain canonical defaults in values.yaml (committed, human-edited).
  2. Maintain per-environment overrides as JSON objects in your deployment scripts.
  3. Convert overrides to YAML on the fly (or pass directly to helm install -f - via stdin).

Helm accepts both --values overrides.yaml and --set flags. Programmatic JSON → YAML pipes are by far the cleanest way to inject computed values without YAML escaping headaches.

Common Scenarios

Generating a Kubernetes Manifest

You build a Deployment definition programmatically as JSON (easier for templating in JS), then convert to YAML for kubectl apply. Round-trip safe for the common case — Deployments, Services, ConfigMaps, Secrets.

Reading a Helm Values File from a Script

A Node.js or Python script needs to read values.yaml. Either parse YAML directly (extra dependency) or convert to JSON once via the tool and check both into git. The JSON copy is easy for the script to consume.

Generating GitHub Actions Workflows

You're generating workflows from a template engine that emits JSON. Convert to YAML and commit — GitHub Actions runs YAML.

Docker Compose Round-Trip

You inherited a long docker-compose.yml and want to programmatically tweak it. Convert to JSON, manipulate with jq or a script, convert back to YAML.

Terraform / Pulumi Output

Some tools output JSON state but you want a human-readable YAML summary for documentation. Convert and paste — the YAML format is dramatically easier for non-engineers to skim.

Migrating From CloudFormation to Terraform

A CloudFormation template (JSON) needs to land in Terraform as HCL, but as an intermediate step you might generate a YAML representation for human review. Convert JSON → YAML, share with the team for sanity-checking, then translate to HCL. The YAML phase makes the structure dramatically easier to read.

Inspecting a Compiled Helm Chart

When debugging why a Helm release behaves unexpectedly, run helm template release-name chart/ --values prod-values.yaml to materialize all manifests. Pipe the output into your editor, copy a single Deployment, paste into a JSON converter to flatten and inspect — much easier than scanning 800 lines of compiled YAML.

Comparing Helm Values Across Environments

Convert each values.yaml to JSON, then run them through PDFFlare's JSON Diff — spots config drift between staging and production instantly.

Best Practices

  • Validate the output before applying.A JSON → YAML conversion is faithful, but YAML's indent-sensitivity means a misaligned line breaks everything. Use kubectl apply --dry-run=client -f file.yaml before applying to a real cluster.
  • Watch out for the Norway problem. Older YAML versions parsed bare no as false — the country code NO would silently become a boolean. YAML 1.2 fixed this, and js-yaml uses 1.2 by default. Still, quote ambiguous strings like "no", "on", "yes"when they're actually country / port / answer values.
  • Pretty-print the JSON first. Run it through PDFFlare's JSON Formatter so you can spot any structural issues before converting.
  • For sensitive values, use Kubernetes Secrets. Don't paste plaintext credentials into a YAML config and check it in. Use a Secret resource and reference it.
  • Keep canonical configs as one format.Don't check in both config.json and config.yaml— they'll drift. Pick one as canonical, convert on demand.

Common YAML Pitfalls Worth Knowing

  • Tabs are illegal as indentation. YAML 1.2 explicitly forbids tab indentation. Some editors auto-tab on enter — kill this for YAML files. The error from kubectl is rarely helpful when this happens; check whitespace first.
  • Trailing whitespace in folded blocks. A multi-line string using > or | includes trailing whitespace on each line. Editors that auto-strip trailing whitespace can subtly change folded-block content.
  • Quoting big numbers. A 64-bit integer like a timestamp 1735689600000 stays a number through YAML and JSON, but watch for precision loss in JS consumers — same issue as JSON. Stringify large IDs at the source.
  • The off / on trap. YAML 1.1 treated bare off and onas booleans. YAML 1.2 (what js-yaml uses) doesn't, but legacy tools or older parsers still might. Quote these values when they mean strings.
  • Mixing flow and block style. YAML lets you write tags: [a, b, c] (flow) or tags:\n - a\n - b (block) — both are valid. Pick one style per file for readability; mixing reads poorly in code review.

Privacy: Your Configs Stay on Your Device

PDFFlare's JSON to YAML converter runs entirely in your browser via js-yaml. Configs containing API keys, database URLs, internal hostnames, or any other secrets never upload anywhere. This is critical for infrastructure-as-code work where pasting into a third-party online tool would be a security incident.

Wrapping Up

JSON ↔ YAML conversion is a daily task in any modern devops or platform-engineering workflow. A bi-directional, browser-based converter that round-trips reliably and doesn't leak your configs to a server is exactly what you want.

Got a Kubernetes manifest, a Helm values file, or a GitHub Actions workflow that needs format conversion? Open PDFFlare's JSON to YAML converter and your config is ready for kubectl in seconds.

Related Tools

  • JSON to TOML — for Cargo, pyproject, and other TOML configs
  • JSON Formatter — pretty-print and validate before converting
  • JSON Diff — compare two configs (after converting both to JSON)
  • JSON Schema — validate the JSON shape before converting to YAML