Convert NDJSON to XML

The two formats sit at opposite ends of the same question. NDJSON is designed so that no line depends on any other: you can split it anywhere, resume it after a failure, and process it without holding it. An XML document is the other extreme — it is not valid until the closing root tag arrives, so the whole thing is one unit from the first byte to the last.

That is the property to plan around rather than the element names. A conversion of a large export produces a single document that has to be transmitted, parsed and accepted as a whole, and a failure anywhere in it fails all of it. Where the receiving system has a message size limit or a retry policy, splitting the source into batches before converting is the difference between a delivery that resumes and one that starts again.

The shape is fixed because the input shape is fixed. A newline-delimited file is always a list, and a list has no name of its own, so the document is a root element containing one item element per record. Each field becomes a child element named after its key, and a nested object becomes nested elements below it.

There is no option to change those two names during the conversion, and there is no sensible way for the converter to guess them — nothing in an NDJSON file says whether the records are orders, claims or measurements. The output is deliberately the plainest correct document, which makes the rename that follows a predictable search and replace rather than an untangling.

Almost every XML intake names its record element in a schema: an Orders document containing Order elements, a Batch containing Transactions. So the two generic names are placeholders, and replacing them is a two-line job in any editor — one occurrence of root at each end, and item on every record boundary.

Doing it before the first delivery rather than after a rejection is worth the two minutes. An intake that validates against a schema will reject the whole document on the element name and will usually report it in a way that does not obviously say so. If deliveries are going to be regular, the rename belongs in whatever script moves the file, not in a person’s memory.

A list in XML has always been the same tag written several times, so a record with three tags produces three tags elements next to each other. No numbering, no joining, no decision made on your behalf — the structure arrives intact.

This is the strongest argument for XML over the tabular targets for the same file. Converting these records to CSV forces a choice between numbered columns, a joined string and extra rows, and each of those loses something. An order with five line items or an event with a list of applied rules converts to XML without any compromise at all, which is often why the receiving system chose XML in the first place.

JSON keys can be anything: spaces, slashes, a leading digit, a currency symbol. XML element names cannot. The writer rewrites rather than failing — characters XML forbids become underscores and a name starting with a digit gains one in front — so a field called "2024 total" becomes a 2024_total element with an underscore ahead of it.

Machine-generated exports hit this more often than hand-written ones. Anything keyed by a date, a metric name, a header field or a customer reference will produce rewritten names, and the rewrite is silent. If the intake has a schema, those elements will fail validation with a name you do not recognise, so it is worth grepping the output for underscores before the first delivery.

The reconciliation that the tabular conversions perform does not happen here, and does not need to. Each item element carries exactly the fields its line had, so a mixed-event file produces item elements of several shapes inside one document — which is valid XML and is usually invalid against a schema.

A schema that declares a fixed sequence of child elements will reject the first record that omits one. Where that is the case, either filter the source to one record type before converting, or add the missing elements as empty ones — and note that an empty element and an element declared nillable are different things to a strict validator. Which of the two the intake wants is a question for their documentation, and answering it once saves a cycle of rejections.

Ampersands, angle brackets and double quotation marks in a value are escaped, which is what stops a product description or a log message containing markup from ending the document early. Everything else, including accented and non-Latin text, is written through as UTF-8.

A JSON null becomes an empty element: the tag is present with nothing between its halves. Some schemas want xsi:nil on those instead, and some want the element absent entirely. If the intake distinguishes them, that is a scripted edit over the output rather than something the conversion can decide, because the source has only one way to say nothing.

Every field name appears twice per record — once in the opening tag and once in the closing tag — where NDJSON writes it once. Add the indentation and a document of small values with long field names lands at two to three times the size of the file it came from.

On an SFTP drop or a file transfer that is irrelevant. On a message queue with a size limit it decides how many records fit in a batch. The answer is almost always compression rather than restructuring: XML of this kind is extremely repetitive and gzips very well, and most intakes that limit message size accept a compressed payload.

Well-formedness first — any XML editor or command-line parser confirms in a second that the document parses, and it should. Schema validation second, and expect the first attempt to fail on the element names, a missing namespace declaration on the root, or element order, since XSD sequences are ordered and JSON keys are not.

Once one document passes, the shape of the work is settled: split the source into batches of whatever size the intake accepts, convert each, apply the same renames and the same root attributes. Doing the first one by hand and reading the validator output carefully is what makes the rest of them mechanical.

The conversion runs in this browser tab: the file is parsed line by line and the document is written by a small writer in the page. Nothing is uploaded, there is no account or queue, and the free tier accepts up to 100 MB, with memory as the practical ceiling because the document is assembled whole.

The data that ends up on this route is rarely trivial. Deliveries to regulators, banks, insurers and partner systems are exactly the files with a confidentiality clause attached, and running the conversion through an unknown web service would be a second disclosure nobody agreed to. There is nothing to disclose here — open the network tab during a conversion and watch.