XML to JSON Converter

Records, not documents

There are two reasons to convert XML into JSON, and they want different output. One is to mirror a document faithfully, tree and all, which usually means writing a schema-aware mapping by hand. The other is far more common: a repeating structure needs to become a list of objects that code can loop over. This page does the second one, and says so up front so you can leave now if you needed the first.

• A legacy endpoint in a modern app. Insurance, logistics, banking and telecom services still answer in XML. The React or Node side of the wall wants objects, not a DOM walk.
• Seeding a document store. MongoDB, Firestore, OpenSearch and DynamoDB all ingest JSON. Handing them an XML export requires this step first.
• Test fixtures from a real response. Capture one live payload, convert it, and you have a fixture your mocks can return without anybody hand typing forty fields.
• Feeds worth tracking over time. Sitemaps, RSS, product feeds. As JSON they diff cleanly in version control and drop into a script in one line.
• Getting XML into a notebook. A list of flat objects loads straight into pandas or Polars, where an unflattened tree would need normalising first.

Most converters for this pair are paste boxes with a character limit. This one takes a file too, up to 100 MB, and reads it locally, which matters when the payload you captured has customer names in it.

One key set, every object

Optional elements are the normal state of XML, not an edge case. A converter that simply mirrors each record produces objects of different shapes, and everything downstream then behaves badly in a way that takes a while to trace. A schema inferred from the first record is wrong for the rest of the file. A CSV writer given that array emits ragged rows. TypeScript types generated from a sample declare fields as required that are missing three hundred records later.

So the keys are collected across the whole document first, then every object is written with all of them. A record that never mentioned a field gets it as null. The order is first seen wins, which is why clearance appears last in both objects above rather than in the middle of the second one.

The one thing this costs you is the ability to tell "the element was absent" apart from "the element was there and empty". Both are null. If that distinction carries meaning in your source, keep the XML around, because the JSON no longer holds the answer.

What the conversion cannot carry

• Namespace prefixes go. A merchant feed of g:id and g:title elements produces keys called id and title. Readable, and almost always what you wanted. The exception is a document that uses two namespaces with the same local name, where both write into one key.
• Mixed content loses the surrounding words. <line>paid <amt>40</amt> today</line> yields an amt key holding 40, and paid and today are gone. An element that has child elements is read through those children only.
• Depth runs out at three levels. Below three levels under the record element, a branch is written into its key as its own text and a note tells you in how many places that happened. Nothing is silently dropped, but the structure at the bottom is flattened to a string.
• Repeated children share a key. Three category elements inside one product write into a single category key, and the last one wins. Repeating groups inside a record need reshaping the tool does not attempt.
• Only the root's children are searched for records. An envelope like response, then body, then rows, then row has nothing repeating at the top, so paste the inner fragment. A document with exactly one record still converts and says the structure may not be tabular.
• Broken XML stops the conversion. An unclosed tag returns the parser's own message with the line and column, rather than a half converted file. Comments and the XML declaration are ignored, and CDATA arrives as ordinary text.