Convert JSON to NDJSON

This is the whole mechanism and it is worth stating before anything else. If the document is an array, each element becomes one line. If it is anything else — an object, a string, a number — the entire document becomes one line, because NDJSON is defined as one complete JSON value per line and a single object is one value.

Neither outcome is an error and the converter will not warn you, so the check is yours: open the file and look at the first character. A square bracket produces the file you wanted. A curly brace produces a single very long line, which is valid NDJSON, loads without complaint into most consumers, and represents one record where you expected thousands.

API responses are almost never a bare array. They are an object with one key — data, results, items, records — whose value is the array. For the tabular conversions on this site that wrapper is unwrapped automatically, because a table has nowhere to put it. On this pair it is not, and the difference catches people.

The reason is that the wrapper is a legitimate record here. NDJSON can hold objects of any shape, so there is no way to distinguish "an envelope to discard" from "a record that happens to contain a list", and guessing would silently discard data on the files where the guess is wrong. The fix is a ten-second edit in a text editor: delete the opening brace and key, delete the closing brace, save, convert. If you are doing this often, jq with the expression .data does the same thing without opening the file.

Every other target for a JSON export on this site has to flatten. A CSV, a TSV, a SQL insert or a Parquet column has nowhere to put an object inside a value, so nesting becomes dotted column names and arrays become numbered ones. NDJSON has no such problem: each line is JSON, so an order carrying a nested customer address and five line items arrives complete.

That makes this the conversion to choose when the structure is the data. If the destination can read newline-delimited JSON — and most warehouse loaders, queue producers and log shippers can — you get the streaming and line-counting properties without paying for them in structure. The flattening conversions are for destinations that genuinely cannot hold a tree.

Each record is written compactly: no indentation, no line breaks inside a record, one space-free line per element. If the source was pretty-printed, the file gets substantially smaller even though nothing was removed, because a formatted JSON export is often more whitespace than data.

Key order within each record is preserved, and no keys are added or dropped. A record that was missing a field in the array is missing it on its line too — NDJSON does not reconcile records against each other the way the tabular writers do, and it does not need to, because there is no shared header to fill in.

A newline inside a string value is escaped inside the JSON, not written literally, so nothing in the data can produce a line break. That is what makes the line boundary a real guarantee rather than a convention: wc -l is the record count, split -l 50000 produces valid chunks, and head -1 shows a complete record.

It also changes what a broken file costs. A malformed JSON array gives you nothing — the parse fails and you cannot tell which record was responsible. A malformed line in an NDJSON file costs you that line, and the converter reading it back will name the line number, which is the difference between a five-minute fix and an afternoon with a hex editor.

There is an irony in this pair worth being honest about. The entire benefit of NDJSON is that a consumer never has to hold the whole file, and producing it here requires exactly that: a JSON array is not valid until its closing bracket arrives, so the document is parsed whole before the first line can be written.

The practical limit is therefore your own memory rather than a size tier, and a document in the hundreds of megabytes is where a browser tab starts to labour. If you are producing the data yourself, the better fix is upstream — have the source emit NDJSON in the first place, which is a one-line change in most exporters and removes the whole-file parse from the pipeline permanently.

A good number take it directly: BigQuery and Snowflake load jobs pointed at newline-delimited JSON, DuckDB reading the file in a FROM clause, ClickHouse with its JSONEachRow format, and most application import routines that describe their input as one object per line.

A smaller set wants a protocol rather than records. Elasticsearch and OpenSearch bulk requests interleave an instruction line before every document, so a body has twice as many lines as records and this output is the raw material for it rather than the payload itself. The way to tell which you are dealing with is to look for the word action or metadata in the format description — if it appears, you are being asked to generate the extra lines.

Nothing about this conversion is one-way. Converting the result back to JSON reassembles the lines into an array, and because each line was already a complete value, the array you get is the array you started with — same records, same nesting, same key order.

That is worth knowing while deciding what to keep. If the NDJSON is a transport artefact for one load, there is no reason to archive it; the JSON is the same information and other tools read it more readily. If records are going to keep arriving, the NDJSON is the better long-term shape, because appending to it is a matter of adding a line rather than rewriting a bracket at the end of a large file.

Not every consumer benefits. If the destination is a program that will read the whole file at once — a test fixture, a seed script, a request body, a configuration import — a JSON array is what it expects, and NDJSON only adds a reassembly step at the other end.

And if the records are going to be queried repeatedly rather than loaded once, neither shape is ideal. Both repeat every key on every record, which is a large share of a real file. A columnar format holds the same rows for a fraction of the bytes and answers a two-field question by reading two fields, which is what a stream cannot do.

In this browser tab, in plain JavaScript, with no upload and no account. The free tier accepts up to 100 MB, and beyond that the constraint is memory rather than any policy of ours.

The privacy point is concrete for anyone preparing a bulk load. The files that get converted for ingest are event logs, order histories, user records and audit trails, and handing one to a web service to have its brackets removed would be a remarkable trade. Nothing is sent anywhere here, which is easy to confirm: open the network tab and convert a file.