Both directions, live in browser, spec-conformant
{{ error }}
JSON is more compact and universally available — great for APIs and machines. YAML is easier to read and write (indentation, comments) and is preferred for configuration files (Kubernetes, Docker Compose, Ansible, GitHub Actions). Both represent the same data types — so lossless conversion is possible (except comments are lost on YAML→JSON).
YAML has surprising edge cases: `no` and `off` are parsed as boolean false in YAML 1.1 (so a Norwegian language code loses its meaning). `1.0` is a number, `'1.0'` is a string. Time values like `12:00` get converted to seconds. For simple configs YAML is pleasant; for complex structures with many special characters JSON is safer.
JSON (RFC 8259 / ECMA-404) and YAML (YAML 1.2.2, yaml.org) are syntactically very different but represent the same data model: scalars, sequences (lists) and mappings (associative arrays). YAML is actually a superset of JSON — every valid JSON is valid YAML too. That makes round-trip conversion mathematically lossless for data, with one important exception: comments. YAML allows # comments, JSON does not. Going YAML → JSON loses comments — for configs that you commit, keep the YAML source.
In practice both formats dominate different territory: JSON is the lingua franca for REST/GraphQL APIs, logs, browser LocalStorage and npm's package.json. YAML is standard in Kubernetes manifests, Docker Compose, Ansible playbooks, GitHub Actions, GitLab CI and MkDocs. If you generate a deployment.yaml in a Helm chart programmatically, the workflow is often: build data in TypeScript/Python, feed it through the build as JSON, output YAML at the end — exactly what our converter does in the browser using js-yaml@4, a spec-conformant parser for YAML 1.2.
A crucial point for clean configs: YAML 1.2.2 has cured the infamous "Norway problem". In YAML 1.1, no, NO, off, OFF, yes, on were automatically parsed as booleans — the ISO code for Norwegian (no) lost its meaning. YAML 1.2 accepts only true and false as booleans. If you work with older tools (e.g. Ruby Psych 1.x or SnakeYAML 1.x), quote such values: language: "no".
Conversion happens live in the browser. Follow these steps:
:, unquoted values containing special characters like : # @ &.Here are typical conversions you encounter in practice:
name: Anna\nage: 29 becomes {"name":"Anna","age":29}. Note that 29 is automatically interpreted as a number.roles:\n - editor\n - author becomes "roles":["editor","author"]. The inline form roles: [editor, author] produces the same.description: |\n Hello\n World is preserved as "Hello\nWorld" with newlines. With > the newlines would be replaced by spaces.apiVersion: apps/v1, kind: Deployment and nested spec.template.spec.containers becomes a well-structured JSON tree — ideal as an API body for kubectl --raw.name: CI\non: [push]\njobs: ... becomes {"name":"CI","on":["push"],"jobs":{...}}. Heads up: in YAML 1.1 on is a boolean — js-yaml@4 (YAML 1.2) correctly keeps it as a string key.YAML is powerful but tricky. First: indentation. YAML accepts only spaces, never tabs for indentation. Mixed indentation or a single tab in a 200-line file breaks the whole parse. Configure your editor with expandtab width 2. Second: anchors and aliases. &name and *name enable reuse of structures — when exporting to JSON, aliases are expanded (referenced sub-structures are duplicated into two separate objects), which makes the JSON noticeably bigger. Third and security-critical — YAML code execution: older YAML parsers (PyYAML <5, SnakeYAML <2) allowed remote code execution via !!python/object/apply or !!javax.script.ScriptEngineManager tags. js-yaml@4 (in the browser) and safe_load (Python) forbid custom tags by default — still, never parse YAML from untrusted source with the unsafe load(). Fourth: Norway problem. YAML 1.1 turns no → false. js-yaml@4 is YAML 1.2 and correctly keeps it as string — but be careful if the consumer speaks YAML 1.1 (some cloud CI systems still do). Fifth: comment loss. YAML → JSON drops every # comment. Keep the YAML source as the single source of truth and JSON only as a machine format.
no, off, yes, on were auto-cast to booleans — the ISO language code for Norwegian (no) lost its string identity. YAML 1.2 (used by js-yaml@4) fixed this. With older parsers, quote them: language: "no".expandtab width 2 or run yamllint in CI.safe_load, SnakeYAML 2.x) yes — they ignore custom tags like !!python/object/apply. With old versions, YAML parsing was a remote code execution vector. Never use yaml.load() without explicit safe mode on untrusted input."_comment":"…", JSONC on the consumer side, or a build pipeline that keeps the YAML source and deploys JSON only as a generated artifact — the most common and cleanest approach.navigator.clipboard API — no server round trip.