Data

YAML Converter

Convert YAML into JSON, TOML, XML, JavaScript object literals, or PHP arrays. Multi-document YAML separated by --- merges into an array, while anchors, aliases, and merge keys (<<: *base) expand into their real structures. The tool covers everyday YAML sources — Kubernetes manifests, Helm charts, Docker Compose files, GitHub Actions and GitLab CI workflows, OpenAPI and AsyncAPI specs, Ansible playbooks, CloudFormation templates — and flags the type traps that quietly bite: the Norway problem, version numbers truncated to floats, big integers losing precision beyond Number.MAX_SAFE_INTEGER, tab indentation, and implicit nulls. Errors come with line, column, and surrounding context. Parsing, conversion, and copying all happen in this browser tab; nothing is uploaded, proxied, or logged on a server.

0 chars
Waiting for input
Conversion result appears here
Actions

Related guides

Overview

A focused tool for work that starts from YAML. Multi-document merging, anchor and merge-key expansion, type-trap detection, and engine-compatibility hints are resolved at parse time so the output is ready for downstream CI pipelines, configuration templates, JSON Schema validators, or code generators without a second manual cleanup pass.

  1. 01

    Five target formats out of the box

    YAML to JSON, TOML, XML, JavaScript object literal, and PHP array. Key sorting and big-integer handling apply to every target; JSON adds indent size; TOML enforces an object root and never emits half-output; XML lets you set the root name, list-item name, declaration, and pretty-print, and accepts a list at the root; JS object literals keep quoted keys and proper escaping; PHP arrays emit a full <?php return [...]; file.

  2. 02

    Multi-document YAML merged automatically

    When one file holds several documents separated by --- (Kubernetes manifests, Helm template renders, kustomize build output, Ansible playbooks), the tool merges them into a JSON array in source order. A toggle limits output to the first document so you can focus on a single Deployment, Service, or Ingress at a time.

  3. 03

    Anchors, aliases, and merge keys expanded

    &base, *base, and <<: *base resolve into real structures during parsing so downstream JSON, TOML, XML, JS object, and PHP array consumers never see dangling references or missing merge fields. The checks panel lists every anchor name it found, so you can still see which references were expanded, and a runaway anchor chain is stopped instead of freezing the page.

  4. 04

    Type-trap and version-compatibility hints

    Detects the Norway problem (country: no parsed as boolean), version numbers truncated to floats (1.10 to 1.1), big integers beyond Number.MAX_SAFE_INTEGER, tabs used as indentation, implicit nulls, and ambiguous octal prefixes — and notes whether the behaviour differs between YAML 1.1 and YAML 1.2 engines.

  5. 05

    Errors with line, column, and context

    When YAML fails to parse, the error pins the exact line, column, and surrounding snippet along with the parser hint, so you can go straight back to the source rather than counting indentation by eye.

  6. 06

    Runs entirely in the browser

    Parsing, conversion, checks, and copy all happen on this page. Your YAML never leaves through a request to a server, CDN, or third-party analytics platform — safe for production manifests, secret sample data, and Cargo.toml migration drafts.

How to use

The workflow collapses into four steps: paste YAML, pick a format, scan the checks panel, and copy the result.

  1. 01

    Paste YAML into the input panel on the left. Parsing happens immediately and the checks panel surfaces document count, anchor list, indentation warnings, and other structural hints.

  2. 02

    Pick a target at the bottom: JSON, TOML, XML, JavaScript object, or PHP array. The option pills — key sort, big integers as text, JSON indent size, XML root and item names — update the output live.

  3. 03

    Read the checks panel. Norway booleans, version-as-float, big integers, and tab indentation are flagged but never block conversion; they mark places worth quoting or fixing in the source.

  4. 04

    Switch to fullscreen for long manifests or large OpenAPI specs. Both input and output panes get more room and the editor keeps syntax highlighting, folding, and copy controls.

  5. 05

    Click copy and paste the output into your IDE, snippet manager, CI job definition, or API client (Postman, Insomnia, Bruno) to continue the workflow.

Details

The recurring rough edges of everyday YAML work are smoothed out by default — no need to chain external tools just to get a clean conversion.

  • Parsing follows YAML 1.2 by default and additionally flags YAML 1.1 risks so output never silently diverges from PyYAML, Symfony YAML, or other legacy runtimes.
  • Output preserves YAML key order by default, with an opt-in alphabetical sort that applies to every target format for stable git diffs, code review, and JSON Schema validation.
  • TOML conversion requires an object root and reports clearly rather than emitting a half-finished TOML that no parser will accept.
  • XML accepts custom root and item names, declaration, and pretty-print to align cleanly with SOAP, RSS, SAML, or Atom schemas already in production.
  • JavaScript object and PHP array outputs preserve nesting, escaping, nulls, and boolean literals so the result drops directly back into test data, Storybook stories, Laravel config, or WordPress examples.
  • Multi-document YAML outputs either as a single array or only the first document, ideal for handling Kubernetes Deployment, Service, and Ingress resources separately.
  • The structure summary lists anchor names, document count, and nesting depth so an unfamiliar YAML file becomes legible in seconds.
  • Everything runs inside this browser tab — no SaaS backend — so the tool keeps working on a flight, in a VPN-only network, or behind an enterprise proxy.

Use cases

Whenever the source is YAML, the following everyday tasks shed a layer of manual copy-paste or screenshot-and-describe.

  1. Audit Kubernetes manifests and kustomize output

    Paste a multi-document bundle of Deployment, Service, Ingress, ConfigMap, and Secret resources, get a JSON array of the full resource set, and feed the result into json-diff to compare pre-release versus production without leaving the browser.

  2. Inspect Helm charts and reconcile values

    helm template renders multiple documents with anchor reuse. Converting to JSON shows the final shape of every resource, exposing where overlapping values.yaml layers cancelled each other out.

  3. Inspect GitHub Actions, GitLab CI, and CircleCI workflows

    Convert workflow files to JSON, then run a structured comparison to see how matrix, env, conditional, and reusable workflow definitions ultimately expand — pinpointing why a job did or did not trigger.

  4. Swap between OpenAPI, AsyncAPI, and JSON Schema

    Teams author specs in YAML, but Stoplight, Swagger Codegen, Prism mocks, and AJV validators sometimes accept only JSON. One conversion keeps a single source of truth and avoids drift between manual copies.

  5. Sync frontend and backend test data and mocks

    Backends commonly keep test data in YAML (Rails, Symfony, Laravel). Frontend Jest, Vitest, and Storybook tests want JSON or JS objects. Convert and paste — no bespoke transformation script required.

  6. Migrate projects to TOML — Cargo, pyproject, Hugo

    Moving a project to Cargo.toml, pyproject.toml, or Hugo config.toml? See the YAML-to-TOML output first, then refine by hand. The structural diff catches typos that line-by-line retyping introduces.

  7. Read Ansible playbooks and CloudFormation templates

    Ansible vars files and CloudFormation SAM templates nest anchors and intrinsic functions deeply. Converting to JSON flattens the visual hierarchy enough for review, training, and onboarding.

  8. Security review and configuration baseline diff

    Inspect anchor chains, nesting depth, implicit types, and unquoted sensitive literals to ensure YAML implicit behaviour does not nudge a production boolean off course. Pair with a JSON diff tool to compare against a known-good baseline.

See also

When the source on your desk is JSON instead — a minified API response, a Helm values dump, the JSON view of a Terraform plan, the output of kubectl get -o json — and you need to walk the opposite direction back into YAML, TOML, XML, CSV, JavaScript object literals, or PHP array files, reach for JSON Converter. Every target format carries its own options — YAML indent and key sort, XML root name and attribute mode, CSV delimiter and header row, TOML key sort, the PHP top-level return wrapper — so the output drops cleanly into the next tool without further rewriting. If the JSON itself needs a cleanup first — pretty-printing, folding deep nodes, pinpointing a syntax error, or inspecting key statistics before deciding which target to convert into — pass it through JSON Formatter, which supports hierarchical collapsing, error-line highlighting, key search, depth statistics, and in-browser format / minify with the same no-upload guarantee. And when you need to know exactly which fields shifted between two YAML revisions — say, a pre-release versus production Kubernetes manifest, two GitHub Actions workflows across environments, or two Helm releases — paste both JSON outputs into JSON Diff to see every add, remove, and modify keyed by JSON Path in a git-style side-by-side view that catches the kind of accidental overrides, implicit type coercion, and indentation slips that a manual diff tends to miss. When the file on your desk is TOML instead — a Cargo manifest, a pyproject file, a Netlify config — the same conversions run from that side in the TOML Converter.

YAML says more than JSON can hold — where the rest goes

A YAML key can be any scalar, a value can carry a tag, and nodes can reference each other. JSON has none of the three. Converting forces all of it into something JSON understands: some of it translates precisely, some of it vanishes without a word. All four below are reproducible with the tool above.

  1. Standard !! tags work; application tags are dropped

    !!str 42 correctly yields "42" and !!int "7" yields 7. Custom application tags do not: !Ref MyBucket comes out as "MyBucket" and !GetAtt [MyBucket, Arn] as ["MyBucket", "Arn"] — the tag itself is gone, with no warning. Convert a CloudFormation, SAM, or CDK template and you get JSON that parses but no longer means anything, because the real encoding is {"Ref": "MyBucket"}. While you are here: !!binary "aGk=" is decoded to bytes and lands in JSON as {"0": 104, "1": 105}.

  2. YAML keys need not be strings; JSON keys must be

    {true: A, "true": B, 1: C, "1": D, null: E} converts to {"1": "D", "true": "B", "": "E"}. The boolean true and the string "true" are one key in JSON, so are the number 1 and "1", and the later one overwrites the earlier. A null key becomes the empty-string key. Five keys in, three out, and the two overwritten values leave no trace.

  3. Duplicate keys are rejected, and you should be glad

    {a: 1, a: 2} does not convert. It reports Map keys must be unique (line 1, column 8) and points at the source. Plenty of YAML runtimes quietly keep the last one instead, which lets a config drift to a value nobody reviewed. Far better to be stopped here than to find out in production.

  4. An alias is a reference; expanding it is a copy

    Define a ten-element array with &a, reference it with ten *a, and the output holds ten full copies rather than ten pointers. A few hundred bytes of YAML can become tens of megabytes of JSON — this is exactly how a YAML bomb works. Before converting a large Helm values file or Kubernetes manifest, check how many times each anchor is used.

Best practices

YAML readability is a double-edged sword: indentation and bare literals lower the barrier to entry but invite surprises at the edges. A few small habits keep conversions predictable across every project.

  • Quote every sensitive literal — yes, no, on, off, true, false, null — so YAML 1.1 compatible engines never silently coerce them to booleans or nulls.
  • Always quote version numbers, serial numbers, phone-style strings, order IDs, Git commit hashes, and ISBNs to prevent float, octal, or big-integer coercion.
  • Use spaces for indentation only — two or four, consistent across the file. Never mix tabs and spaces, and configure your editor to display whitespace explicitly.
  • Reuse structure with anchors and aliases instead of copy-pasting blocks; merge keys (<<: *base) let you centralise shared fields without duplicating them across resources.
  • After converting YAML to JSON, run the result through json-diff against the previous version to catch silent field changes. Wiring this into CI guards against regressions in config-driven systems.
  • After converting multi-document YAML, confirm array order matches the source file — especially for order-sensitive resource chains like Kubernetes namespaces, CRDs, and Operators.
  • Before submitting a production manifest, run it through this tool to confirm that anchor, merge, and include expansion did not introduce unintended field overrides.
  • YAML binary, timestamp, and custom tags can lose semantics when converted to JSON or TOML. Prefer explicit string literals and document the intended type in the source.

Limitations

Knowing what the tool does not do keeps you from reaching for it as a full YAML IDE, schema validator, or GitOps pipeline.

  • No business-schema validation: Kubernetes API objects, OpenAPI field constraints, JSON Schema, and Cargo manifest field rules are out of scope — syntactic success is not semantic correctness.
  • YAML comments are not preserved; JSON, TOML, and XML outputs drop everything after #. Promote essential comments to dedicated fields or external documentation if they must survive conversion.
  • The tool never rewrites your source file. All edits go back through the original document so version control stays the single source of truth.
  • Very large files (hundreds of thousands of lines, multiple megabytes) may slow the browser, but processing stays local — nothing is truncated or uploaded. Validate options against a representative slice before attempting the full document.
  • Custom YAML tags such as !!python/object, !!js/function, or the CloudFormation shorthand !Ref are never executed, so no deserialisation vulnerability can fire. They are left unresolved and the checks panel lists them, because the plain value survives the conversion while the tag meaning does not.
  • No version control, collaboration, comments, or Git integration: the tool is built for single-shot conversion and inspection. Pair it with your Git workflow for review and approval.
  • Target formats have their own limits: TOML needs an object at the root and has no null at all, XML and PHP carry no type information beyond text, and none of them can express a YAML reference. The checks panel names each conflict rather than producing misleading output.

FAQ

Common questions cover multi-document handling, anchors and merge keys, type traps, and whether data leaves the browser.

What if my YAML contains several documents?

Documents separated by --- are recognised automatically and merged into a JSON array in source order, ideal for Kubernetes manifests, Helm renders, and Ansible playbooks. The options panel also lets you keep only the first document when you want to focus on a single resource.

Are anchors, aliases, and merge keys preserved?

They expand into real structures. JSON, TOML, XML, JS objects, and PHP arrays have no concept of a reference, so expansion is the only faithful choice and it prevents downstream tools from seeing dangling aliases or missing merge fields. The checks panel lists every anchor name found in the source, which is usually what you need when you are tracing where a merged field came from.

Why does country: no become false in JSON?

That is the famous Norway problem. YAML 1.1 parses yes, no, on, and off as booleans, which means the ISO country code NO becomes false the moment quotes are missing. The tool follows YAML 1.2 by default but flags the risk so output stays consistent with PyYAML, Symfony YAML, and other YAML 1.1 runtimes. Quoting the value is the safest fix.

My version number 1.10 turned into 1.1. Why?

Unquoted 1.10 in YAML parses as the float 1.1 because trailing zeros after the decimal are dropped. Quote version numbers, phone-style strings, serial numbers, ISBNs, and Git commit hashes — anything that looks numeric but is really a string. The checks panel highlights the suspicious values it finds.

Why does TOML conversion say the root must be an object?

TOML requires a table at the top — arrays, strings, numbers, and null are not valid root values. If your YAML root is a list such as [a, b, c], wrap it with a key like items: [a, b, c] before converting. The wrapper gives the array a meaningful name and satisfies TOML semantics simultaneously.

Why do large integers lose precision?

JavaScript Number caps at 2^53 - 1. Snowflake IDs, integer-form UUIDs, and large timestamp values exceed that range and become approximations once they hit JSON. The checks panel flags every affected value, and turning on big integers as text writes them out with all their digits as strings. Quoting them in the YAML source is still the durable fix.

Does pasted data get uploaded?

No. Parsing, conversion, checks, and copy all happen in the browser. No request carries your YAML out of this page to a server, CDN, or analytics platform. Closing the tab leaves nothing behind — safe for production manifests, secret sample data, and migration drafts alike.

Can I use it offline?

Once the page has loaded, the browser already has every resource it needs for parsing and conversion. The tool keeps working without network access, which is helpful on a flight, behind a strict corporate proxy, or inside an air-gapped network.

Related tools

Keep moving through data work: convert JSON back into YAML, tidy JSON structure, pinpoint nested syntax errors, or compare two outputs side by side. The tools below chain into a full workflow.