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 by default. 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.
- One input feeds five targets — JSON, TOML, XML, JavaScript object literals, and PHP arrays — each with its own per-format options
- Multi-document YAML (--- separated) merges into a JSON array in source order so Kubernetes manifests and Helm renders can be read at once
- Anchors, aliases, and merge keys expand into full structures so downstream JSON, TOML, and XML never see dangling references
- Smart detection for YAML 1.1 compatibility traps: Norway booleans, version-as-float (1.10 → 1.1), big-integer precision loss, tabs in indentation, implicit nulls
- Fully local processing — no upload, no telemetry — safe for production manifests, secret fixtures, and migration drafts
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.
- 01
Five target formats out of the box
YAML to JSON, TOML, XML, JavaScript object literal, and PHP array. JSON exposes indent size and alphabetical key sort; TOML enforces an object root and never emits half-output; XML lets you set the root name, list-item name, declaration, and pretty-print; JS object literals keep quoted keys and proper escaping; PHP arrays emit a full <?php return [...]; file.
- 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.
- 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. You can switch expansion off when you need to inspect the raw reference shape for debugging.
- 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.
- 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.
- 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 fixtures, 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.
- 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.
- 02
Pick a target at the bottom: JSON, TOML, XML, JavaScript object, or PHP array. Each format has its own option pills — indent size, key sort, anchor expansion, XML root name — that update the output live.
- 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.
- 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.
- 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.
- JSON output preserves YAML key order, with an opt-in alphabetical sort 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 fixtures, 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 in the browser worker — 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.
-
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 whole stack, and feed the result into json-diff to compare pre-release versus production without leaving the browser.
-
Debug 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.
-
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.
-
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.
-
Sync frontend and backend fixtures and mocks
Backends commonly keep fixtures in YAML (Rails, Symfony, Laravel). Frontend Jest, Vitest, and Storybook tests want JSON or JS objects. Convert and paste — no bespoke transformation script required.
-
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.
-
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.
-
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.
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 or !!js/function are ignored or rejected to avoid deserialisation vulnerabilities — no untrusted code execution ever happens.
- 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.
- Some YAML-to-XML or YAML-to-CSV conversions hit structural mismatches (root arrays, mixed-type lists) that cannot be mapped cleanly — the tool surfaces the 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?
By default they expand into real structures. JSON, TOML, XML, JS objects, and PHP arrays do not support references, so expansion is the safer choice and prevents downstream tools from seeing dangling aliases or missing merge fields. Switch the option off when you specifically need to inspect the raw reference graph for debugging.
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 risky values; the durable fix is to keep them as quoted strings in the YAML source.
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 fixtures, 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.