JSON ⇄ YAML / XML
Four-way conversion between JSON, YAML and XML (with attribute and text-node conventions) — API debugging and config migration in one place.
>_ USAGE GUIDE
Four-way conversion between JSON, YAML, and XML in one place: JSON ↔ YAML and JSON ↔ XML, with the source and target formats chosen per request and results produced in real time. Typical scenarios: migrating a YAML config to JSON (or back), calling a legacy API that returns XML while your code speaks JSON, or aligning configuration formats across systems.
- Pick the source format: JSON, YAML, or XML
- Paste your data: it is parsed locally and shown as JSON
- Choose the target format: convert to YAML or XML and copy the output
- Verify after migration: load the converted config in the target system once before shipping
XML-specific structures are mapped by convention: attributes become keys prefixed with @, and element text becomes the #text key, so round-trips preserve information. Arrays, nesting, and scalar values convert directly in every direction. Everything runs in your browser — configs containing secrets stay on your machine, and the page works offline.
>_ FAQ
Q1 · Why is JSON the hub format for conversion?
The three formats have different information models. YAML and JSON are closely related — YAML is effectively a superset — so conversion between them is nearly lossless. XML has concepts JSON lacks, such as attributes and text nodes. Using JSON as the single intermediate hub keeps the rules clear and behavior predictable: any pair of formats converts as "source → JSON → target".
Q2 · Where do XML attributes go after conversion to JSON?
XML attributes and text nodes have no direct JSON equivalent, so an industry convention is used: attributes become keys prefixed with @, and element text becomes the #text key. For example, <book id="1">Title</book> converts to { "@id": "1", "#text": "Title" }. The reverse conversion follows the same convention, so round-trips stay consistent.
Q3 · Does converting between YAML and JSON lose information?
Essentially no — both express the same data structures (objects, arrays, scalars) with different syntax. Two caveats: YAML date values become strings in JSON, and comments are dropped because JSON has no comment syntax. If your config relies on comments, record them elsewhere before converting.
Q4 · Should my config file be YAML or JSON?
Follow your ecosystem and maintainers: Kubernetes and most CI systems live in YAML; frontend tooling and package manifests live in JSON. Choose YAML when humans edit the file often and comments matter; choose JSON for machine-to-machine reads and strict schema validation. After migrating with this tool, always run one full load test in the target system.
Q5 · Will key order be preserved after conversion?
JSON and YAML preserve the original key order. XML does not guarantee attribute order, so attribute keys may come out in a different order than the source document. If order matters — signature concatenation, for example — do not rely on the converter; sort keys explicitly in the source system by a fixed rule.