XML to JSON Converter — Online & Private

How XML to JSON conversion works

XML to JSON Converter — Online & 100% Client-Side | SyntaxFiddle runs XML documents through a deterministic, fully client-side pipeline and produces JSON output in a single pass — no round-trips, no queues, no waiting on someone else's server. Paste an XML document into the input pane — the repeated record element becomes the rows, with attributes as @-prefixed columns. Press Run Conversion (or just pause typing — the studio parses as you go), and the generated output appears on the right with line numbers, syntax highlighting, and one-click copy or download.

Record extraction from XML documents

The parser reads the XML document in your browser, then locates the repeating record element depth-first — the <book> inside <books>, the <item> inside <channel>, the row element inside every export format ever shipped. That element becomes the table: one row per occurrence, with attributes surfacing as @-prefixed columns and nested elements flattening to dot paths exactly like the JSON parser. Namespaces are kept as written, so atom:feed never silently collides with a local feed element.

Scalar values are sniffed conservatively — true/false and round-trippable numbers convert to native types, while leading-zero identifiers and version strings stay text. When no repeating element exists, the converter rejects the document with a precise message instead of guessing which element you meant, and malformed XML reports the line and column so you fix the document rather than debug the output.

XML to JSON: the conventions, stated up front

Every XML-to-JSON converter makes judgment calls; this one publishes them. Attributes become @-prefixed properties, repeated sibling elements become arrays while single occurrences stay scalars, mixed content concatenates into #text, and empty elements become null. Namespaced tags are kept exactly as written — atom:feed stays atom:feed — because silently stripping prefixes is how two different elements collapse into one key. None of these rules is exotic; together they are the closest thing the ecosystem has to a standard mapping, and every one is applied deterministically.

The scalar rules are the conservative set: true/false and round-trippable numbers convert to native JSON types, while leading-zero identifiers, phone numbers, and version strings stay strings — the values a force-cast would corrupt. CDATA is preserved verbatim with no sniffing, entities (named and numeric) are decoded, and malformed XML is rejected with a line-and-column diagnosis instead of a best-effort tree. The JSON out is the XML in, translated honestly.

Output schema: an array of typed objects

The converter emits a single JSON array in which every spreadsheet row becomes an object and every trimmed header becomes a key: [{"Id": "001xx...", "Amount": 1200.5, "IsActive": true}]. This array-of-objects shape is exactly what REST APIs, NoSQL importers, jq, and every major language runtime expect, so the output can be piped straight into fetch(), requests, or a document database with zero reshaping.

Value types follow the source. Excel cells arrive as real numbers and booleans and are serialized natively — 1200.5 stays a number and true stays a boolean. CSV is text by nature, so values are preserved exactly as written: amounts remain strings rather than being silently rounded or reformatted, and leading zeros in codes such as 0012 survive intact. Keys are never mangled; duplicate headers are disambiguated with a numeric suffix so no field is ever overwritten by its neighbor.

Pretty-printing versus minified output

By default the output is pretty-printed with two-space indentation — the human-friendly form that diffs cleanly in code review, reads well in documentation, and parses unchanged. Toggling Minify output strips every byte of insignificant whitespace and emits one compact line, typically 20 to 40 percent smaller, which is what you want when embedding a payload in a config file, shipping it over the wire, or feeding a size-limited API endpoint.

Both forms are byte-identical after JSON.parse, so the choice is purely operational: pretty for humans reviewing the data, minified for machines consuming it. Either way the JSON is guaranteed valid — JSON.stringify escapes quotes, backslashes, and control characters in your data, so even cells containing snippets of JSON themselves round-trip safely.

Private by architecture: your data never leaves the browser

Every stage of this conversion — parsing, type inference, and output generation — executes locally inside your browser's JavaScript engine. The input is never transmitted, logged, or stored: there is no upload endpoint, no queue, no telemetry, and no account to create. Files larger than 1MB are handed to a background Web Worker so the interface keeps animating at 60fps even on hundred-thousand-row imports, and the page keeps working offline once loaded because it is a fully static export.

That architecture makes the tool safe for the exports you would never paste into a random website: customer PII, financial line items, internal Salesforce extracts, and unreleased product data. Paste it, convert it, copy or download the result — and the bytes never moved from your machine.

Limits and practical tips

Inputs are capped at 15MB per file or paste — hundreds of thousands of rows in practice — purely as a browser-safety guard rather than a server policy, since there is no server involved at all. Processing is single-pass and deterministic: the same input with the same options always produces byte-identical output, which makes the generator safe to keep in CI pipelines and documentation. For API payloads and config embeds, prefer minified JSON; for review workflows and diffs, keep pretty-printing on.

How do I convert XML to JSON?

Paste your XML document into the input pane, pick JSON as the target, and press Run Conversion. The parser runs entirely in your browser, applies the documented XML-to-JSON conventions, and produces clean JSON you can pretty-print or minify with one click before copying.

How are XML attributes converted?

Attributes become properties prefixed with @ — id="1" becomes "@id" — because attributes and child elements can share names and the prefix keeps them unambiguous. Attribute values go through conservative scalar sniffing: true/false and round-trippable numbers convert, everything else stays a string.

What do repeated elements and mixed content become?

Repeated sibling elements with the same tag become JSON arrays, and an element appearing once stays a single value — the same evidence-based rule the schema tools use. Mixed content (text interleaved with child elements) is concatenated into a #text property so nothing is dropped, and empty elements become null.

Is the XML to JSON conversion really private?

Yes. Parsing and generation run in a Web Worker inside your browser — there is no upload endpoint, nothing is logged, and the page keeps working offline once loaded. SOAP envelopes, invoices, and internal feeds never leave your machine by architecture, not by policy.

What XML is not supported?

DTDs and processing instructions are skipped, and the parser rejects malformed documents with a line-and-column diagnosis instead of producing wrong JSON. Entity references (named and numeric) are decoded, CDATA is preserved verbatim, and namespaces are kept as written — atom:feed stays atom:feed.

Why do attributes have an @ prefix in the JSON output?

Because attributes and child elements live in the same name space and can collide — an element with both an id attribute and an <id> child needs both to survive. The @ prefix (the convention used by mainstream XML-to-JSON libraries) keeps them distinct and makes the mapping back to the source document unambiguous. It is documented, deterministic, and applied to every document identically.

Will an element that appears once ever become an array?

Only if it repeats in the document you paste — the converter types what it observes, honestly. If you know a field always carries multiple values, paste a document where it does (or two documents and merge), rather than trusting a tool that guesses every element might repeat. Consistent input produces consistent JSON, and the rules never vary between runs.