JSON to YAML

Convert JSON into clean YAML for config files. Free, in your browser.

Converts JSON to YAML in your browser — handy for config files.

Free to use — premium coming soon

FREE
  • Clean YAML output
  • Copy
  • 100% private
PREMIUM
  • Remove ads
  • Multi-document & options

About the JSON to YAML

JSON to YAML converts a JSON document into the equivalent YAML, the indentation-based format used across most modern configuration tooling. Both describe the same data model of objects, arrays, strings, numbers, booleans and null, so the conversion is a faithful re-encoding rather than a translation: every JSON object becomes a YAML mapping, every array becomes a sequence of dashed items, and braces, brackets and most quotes simply fall away. The result is a flatter, less noisy file that reads closer to plain notes than to code, which is exactly why teams reach for YAML once a config grows past a handful of keys.

Use this tool when something hands you JSON but the system that consumes it expects YAML. That happens constantly: Kubernetes manifests, Helm charts, Docker Compose files, GitHub Actions and GitLab CI pipelines, and Ansible playbooks are all conventionally written in YAML, yet APIs, exports and code often emit JSON. Pasting JSON straight into a YAML field usually works, since under YAML 1.2 every valid JSON document is also valid YAML, but it looks out of place and cannot carry comments. Converting first gives you clean, idiomatic YAML you can annotate, diff and review like the rest of your config.

The conversion runs entirely in your browser. The tool parses your JSON into an in-memory structure, then serialises that structure back out using YAML's block style: two-space indentation for nesting, a dash and space for list items, and key-colon-value pairs for mappings. Strings that could be misread as numbers, booleans or dates get quoted automatically so their meaning is preserved. Because YAML has no braces to mark scope, indentation alone defines structure, so the output is carefully aligned, never mixes tabs with spaces, and keeps every nesting level consistent.

Nothing you paste is uploaded or stored on a server, which matters because config files frequently contain secrets, internal hostnames or API keys. The trade-off to understand is fidelity, not privacy: JSON and YAML share the same data types, so a round trip is lossless, but YAML can express things JSON cannot, such as comments and anchors. Converting from JSON simply will not invent those, so the output is the plain, comment-free equivalent of your input. If a value matters as text, check that it stayed quoted after conversion before committing the file.

Frequently asked questions

Is converting JSON to YAML lossless?

Yes. JSON and YAML describe the same data model (objects, arrays, strings, numbers, booleans, null), so converting JSON to YAML preserves every value and structure. The only things YAML can add that JSON lacks, like comments and anchors, simply won't appear because they weren't in your JSON to begin with.

Why does the tool put quotes around some of my string values?

YAML guesses types from how a value looks, so unquoted text like NO, yes, off, or 0123 can be read as a boolean or number instead of a string. Quoting these ambiguous values keeps them as the strings your JSON intended, avoiding the classic YAML "Norway problem" where the country code NO turns into false.

Can I paste the YAML straight into a Kubernetes or Docker Compose file?

Usually yes. The output uses two-space indentation and standard block style that Kubernetes, Docker Compose, and CI tools expect. Just confirm the indentation level matches where you paste it, since YAML uses indentation rather than braces to define structure.

Does YAML support comments after conversion?

YAML supports comments (lines starting with #), but converting from JSON cannot create them because JSON has no comment syntax to carry over. You get clean, comment-free YAML that you can then annotate by hand.

Is my data sent anywhere when I convert it?

No. The conversion happens entirely in your browser, so your JSON, including any secrets or internal hostnames in a config file, is never uploaded or stored on a server.

From our blog

How to Build Realistic CSS Box-Shadows: From Flat to Layered Depth

By the Super Simple Digital Tools Team · Updated June 2026

A single default box-shadow tends to look flat and a little generic because real shadows are not one solid blob. In the physical world, light casts a sharp close shadow and a softer, wider one at the same time, plus a faint ambient darkening underneath. Replicating that in CSS is the difference between a card that looks pasted on and one that looks like it is genuinely floating above the page. The good news is that the property gives you all the controls you need; you just have to understand what each value contributes before you start combining them.

Start with the two required offsets. Think of them as the position of the light source: a shadow that falls down and slightly right (positive offset-y, small positive offset-x) reads as overhead light, which is what users expect. Keep vertical offset larger than horizontal for most interface elements, since lighting in apps is usually treated as coming from above. Once the direction feels right, add blur to control softness. Higher elevation surfaces cast softer, more spread-out shadows, so a tooltip hovering close to the page should have a tighter shadow than a modal floating well above it.

Spread is the value people most often forget, yet it changes the whole character of a shadow. A positive spread grows the shadow outward before blurring, which is useful for glow effects and chunky elevation. A negative spread pulls the shadow in, which is perfect when you want the shadow to peek out only at the bottom of an element rather than haloing all four sides. Pairing a small negative spread with a downward offset is a quick way to get a grounded, weighted look instead of a uniform floating ring.

The biggest upgrade comes from layering. Stack two or three comma-separated shadows in one declaration: a small, low-blur shadow for the crisp contact edge, and a larger, higher-blur shadow at lower opacity for the soft ambient cast. This mirrors how design systems handle elevation, where each level is built from multiple light contributions rather than a single shadow. Three layers is almost always enough; past that the visual gain is negligible and every extra shadow is more work for the browser to paint, especially during animation.

Finally, mind your color. Pure black shadows look muddy and artificial against colored or off-white backgrounds. Use a dark, slightly desaturated version of the background hue with a low alpha, often in the 0.1 to 0.25 range, so the shadow tints naturally rather than smearing gray over everything. When you want a focus ring or a hairline divider that will not shift your layout, set blur to zero and use spread alone, for example 0 0 0 3px of a brand color. Tune all of this live in the generator, then copy the finished declaration straight into your stylesheet.

  • Keep vertical offset larger than horizontal so shadows read as overhead light, which matches how most interfaces are lit.
  • Layer a tight low-blur shadow with a wider soft one in the same declaration to get convincing depth instead of a flat single shadow.
  • Use rgba or hsla with low alpha (around 0.1 to 0.25) and a dark, slightly desaturated hue rather than solid black for natural-looking shadows.
  • For a focus ring or border that never causes layout shift, set blur to 0 and use spread only, such as 0 0 0 3px color, since box-shadow does not change element size.

Read the full guide →

Tool by the Super Simple Digital Tools Team. Reviewed by our editorial team. Free to use, no signup required.

Related tools