XML ⇄ JSON Converter
Bidirectional XML ↔ JSON with attribute handling, CDATA preservation, BOM, line-ending, and indent control
Input
Output
XML ⇄ JSON Converter
Bidirectional XML ↔ JSON with attribute handling, CDATA preservation, BOM, line-ending, and indent control
Features
- Auto-detect mode sniffs whether the pasted text is XML or JSON and runs the conversion in the opposite direction — paste either side without switching mode manually
- Two attribute strategies: Prefix mode emits XML attributes with a configurable prefix (default `@`) as sibling JSON keys, Object mode collects them into a separate `$` object so element text and attributes never collide
- CDATA and text-node handling: when 'Treat CDATA/Text as #text' is on, element text content is folded into a `#text` property so mixed content survives the JSON round-trip; off mode preserves the structural distinction
- Pretty-print toggle with selectable indent (2 / 4 / 8 spaces) for both JSON and XML output — flip on for human reading, off for compact transport
- Line-ending control (LF vs CRLF) for compatibility with Unix vs Windows tooling, plus an optional UTF-8 BOM toggle for systems that require the byte-order mark
- Configurable attribute prefix lets you match downstream conventions: `@` (default), `_`, `xml:`, or any other string — keeps the converted output drop-in compatible with your existing pipeline
- One-click Copy and Download (`converted.txt`) for the output; conversion errors are surfaced inline with the underlying parser's message so you can tell whether the XML was malformed or the JSON wasn't representable as XML
- Pure client-side: parsing uses the browser's built-in DOMParser for XML and JSON.parse for JSON. No network calls, works offline once the page is cached
How to use
- Paste your XML or JSON into the Input pane. With Mode set to Auto-detect, the converter sniffs the format automatically.
- Adjust the Pretty toggle and Indent size to control the output formatting; flip Line ending between LF and CRLF as your downstream tooling requires.
- Open Advanced settings to pick the Attribute mode (Prefix or Object), set the Attribute prefix, and toggle CDATA/Text-as-#text handling.
- Click Convert. The Output pane shows the result; the conversion runs in your browser using DOMParser + JSON.parse.
- Use Copy to put the result on your clipboard, or Download to save it as `converted.txt`.
- If parsing fails, an inline error row shows the underlying message — fix the input and convert again.
Tips & Best Practices
- When debugging an XML payload from a SOAP service, Auto-detect + Object attribute mode + CDATA-as-#text gives the cleanest JSON view.
- Set Line ending to CRLF and enable the BOM when generating output destined for legacy Windows tooling.
- Switch Attribute prefix from `@` to `_` if your JSON consumers reject keys starting with `@` (some YAML-derived parsers do).
- If JSON-to-XML output puts elements in the wrong order, re-insert your top-level keys in the source JSON in the order you want them emitted.
- Combine with JSON Formatter when you want to inspect or transform the converted JSON further; use XML Formatter on the XML side.
FAQ
How does the Attribute mode change the JSON output?
In Prefix mode, XML attributes appear as sibling keys with the configured prefix — `<user id="42"/>` becomes `{ "user": { "@id": "42" } }`. In Object mode, attributes are collected under a single `$` (or implementation-defined) key, so element content and attribute content never share a namespace. Pick Prefix when consumers expect flat keys; pick Object when you need to round-trip attributes back to XML without ambiguity.
What's CDATA-as-#text for?
XML has two ways to hold text — `<a>plain</a>` and `<a><![CDATA[plain]]></a>`. When the option is on, both forms collapse to a `#text` key in JSON, so mixed-content elements like `<p>Hello <b>world</b></p>` survive the JSON round-trip. Off keeps the structural distinction; useful when the original document's CDATA markers are semantically meaningful (e.g. embedded scripts).
Why does the BOM toggle matter?
Some Windows tools (Excel, older PowerShell, .NET's TextReader without explicit encoding) expect a UTF-8 BOM (`EF BB BF`) at the start of a file to detect encoding correctly. Modern web tooling and Unix-style pipelines usually treat the BOM as noise. Enable the toggle when feeding the output to a BOM-aware Windows tool, disable it for everything else.
Why LF vs CRLF?
Windows tools and older Microsoft formats expect `\r\n` (CRLF) line endings; Unix/Linux/macOS default to `\n` (LF). Git typically normalises both, but artifacts that bypass git (downloads, clipboard pastes into Notepad, build outputs) need the explicit choice. The Auto-detect parser ignores line endings, so this control only affects the output.
Will namespaces survive the conversion?
Namespace-prefixed element and attribute names round-trip as literal strings (e.g. `xmlns:soap` becomes the key `@xmlns:soap`). The converter doesn't resolve namespaces against URIs — if your downstream pipeline needs namespace resolution, do that step separately. Round-tripping back to XML preserves the prefixes you started with.
What happens to empty elements?
An empty XML element `<a/>` becomes `{ "a": null }` in JSON (or `{ "a": "" }` if it was `<a></a>` with empty text and CDATA-as-#text is on). When going JSON to XML, a `null` value emits a self-closing element. Round-tripping is stable as long as you don't toggle the CDATA-as-#text setting between the two directions.
Why does my JSON-to-XML output have ordered keys?
XML elements have a defined order; JavaScript objects preserve insertion order for string keys, so the converter writes elements in the order their keys appeared in the JSON. If the JSON came from a JSON.parse round-trip the order matches the source; if you built it programmatically, control the order by inserting keys in the desired sequence.
Are large documents safe to convert in this tab?
Mid-megabyte documents convert in well under a second. Very large documents (>10 MB) work but pin the UI thread for the duration of the parse; for that workload, run the same logic in a Web Worker or a build-time script. The conversion service is the same in both contexts.