Skip to content
epitometool

XML ↔ JSON

JSON & data

Convert XML to JSON and back — attributes preserved, no XXE, all client-side.

Updated

Direction

Options

XML input

JSON output

  • EnterCopy output
  • KClear input

Quick start

How to convert XML to JSON (and back)

Paste XML or JSON, pick a direction, see the converted output instantly.

  1. Step 1
    Pick a direction

    Toggle between XML → JSON and JSON → XML at the top of the page. The output pane updates as you type.

  2. Step 2
    Tune the convention

    Choose the attribute prefix (@ by default), the text key (#text by default), and whether to coerce numeric strings to numbers.

  3. Step 3
    Copy

    Click Copy (or ⌘/Ctrl + Enter) to grab the output. Use Swap to round-trip back to the original format.

In-depth guide

XML ↔ JSON converter — no upload, no XXE

Convert between XML and JSON in either direction, entirely in your browser. Parsing uses the native DOMParser — no external library, no server round-trip, no external-entity resolution. Bring any RSS feed, SOAP envelope, configuration file or API response.

The mapping convention

XML has three structural concepts JSON doesn't: attributes, mixed content (text alongside child elements) and ordered children. We use a popular convention that handles all three without exotic syntax.

XMLJSON
<a>hi</a>{ "a": "hi" }
<a x="1">hi</a>{ "a": { "@x": "1", "#text": "hi" } }
<a/>{ "a": null }
<list><i/><i/></list>{ "list": { "i": [null, null] } }

The attribute prefix (default @) and text key (default #text) are configurable in the options panel — match what your downstream consumer expects.

Strings vs typed values

XML carries no type information. <count>007</count> could be the string "007" (e.g. an employee ID with leading zeros) or the number 7 (a count). The same goes for "true", "null" and other strings that look like literals in other languages.

The default is strings only, which is lossless. Enable Coerce numbers/booleans when you know your data is well-typed and want JSON numbers / booleans out.

Round-tripping

The pairing of xmlToJson and jsonToXml under the default convention is round-trip-safe for the structure of the document: elements, attributes, element order within a parent, repeated siblings as arrays.

What can drift on a full round trip:

  • Whitespace outside elements is normalised on the way back — pretty-printing your XML, converting, converting back gives you a freshly indented document.
  • Attribute order within a single element follows object-key iteration order on the way back, which may differ.
  • Comments are dropped by default (toggle off in options to keep them as #text entries).
  • Mixed content (text interleaved with child elements at the same level) is lossy — all text fragments are concatenated.

Security: XXE and entity expansion

"XML External Entity" (XXE) is a classic vulnerability where a parser resolves <!ENTITY foo SYSTEM "file:///etc/passwd"> and exposes the contents. The browser's DOMParser spec explicitly does not resolve external entities — they're treated as opaque text. No additional hardening required.

"Billion laughs" (entity expansion DOS) is similarly mitigated: internal entity declarations are honoured at the parse step, but browsers cap nested entity expansion well before it becomes a resource issue.

You can paste XML from an untrusted source without worrying about either class of attack.

When to use it vs alternatives

Use this tool for quick inspection, cleanup, conversion, and copy-paste debugging. Use your IDE formatter, schema tests, or CI checks when the same rule needs to be enforced across a repository.

Common pitfalls

  • Validate the output before committing it, especially when fixing almost-valid input.
  • Escaping, comments, trailing commas, and mixed encodings are the usual source of surprising results.
  • For production config, keep a copy of the original until the consuming system accepts the rewritten file.

Frequently asked questions

Is my data uploaded to a server?

No. Both XML parsing (via the browser's built-in DOMParser) and JSON serialisation run entirely on your device. Nothing is sent over the network.

Which XML→JSON convention does it use?

A pragmatic mapping similar to BadgerFish / Parker: attributes get a configurable prefix (default `@`), text content lives under a configurable key (default `#text`), repeated child elements become arrays, and bare element-with-text becomes a scalar. The prefix and text key are configurable in the options panel.

Why are numbers and booleans returned as strings?

XML is fundamentally a string format — `<count>007</count>` and `<active>true</active>` are not typed. Coercing them to JSON numbers/booleans can silently lose leading zeros (`007` → `7`) or misinterpret strings that look like booleans. Enable "Coerce numbers/booleans" in the options to opt into coercion when you know your data is clean.

Does the JSON→XML direction preserve attributes?

Yes — any key starting with the attribute prefix (default `@`) becomes an XML attribute. The rest of the keys become child elements; the special text key (default `#text`) becomes inline text. Arrays produce repeated sibling elements with the same tag name.

How does it handle XML namespaces?

Element and attribute names are preserved including the prefix, e.g. `<atom:link>` becomes the key `atom:link`. The `xmlns:...` declarations also come through as attributes. Round-tripping XML → JSON → XML preserves namespaces structurally but may reorder attributes.

Is XXE (XML External Entity) injection possible here?

No. Modern browser DOMParser implementations do not resolve external entities by default — that's been the spec behaviour since the DOM Parsing and Serialization spec (W3C). External DTD references in pasted XML are inert.

What about mixed content (text and elements interleaved)?

All text node siblings are concatenated and placed under the text key (default `#text`). If you need to preserve interleaving order, this convention is lossy — consider a richer format like XAST or an XML-AST representation.

Why does JSON → XML require a single root key?

Every XML document must have exactly one root element. `{ "a": 1, "b": 2 }` has two top-level keys with no shared parent, so there's no unambiguous XML. Wrap your data: `{ "root": { "a": 1, "b": 2 } }`.

Keep exploring

More tools you'll like

Hand-picked utilities that pair well with the one you're on — all free, client-side, and zero-signup.