Sehr große JSON-Dateien konvertieren

Quick answer

To convert very large JSON files (100 MB to several gigabytes) without crashing your browser or running out of memory, never paste raw text into a textarea; instead, use file streaming. Stream records in chunks through a dedicated Web Worker off the main thread, or adopt line-delimited JSON (JSONL) so records are parsed and emitted incrementally. You can convert gigabyte-scale datasets locally with zero uploads using our streamed JSONL to CSV converter.

---

“Large” starts sooner than people expect, and the thing that fails first is usually not the one you would guess. This is what breaks, in the order you will hit it.

The textarea fails first

Pasting is the slowest path into any browser-based tool. A textarea holding fifty megabytes of text has to lay that text out, maintain a cursor in it, and hand a single enormous string to the reader — and the layout work happens on the main thread, so the page stops responding before the conversion has even started.

Use the file picker or drag the file in. The file is then read in chunks and never becomes one giant string, which removes the whole problem. Above roughly ten megabytes this is the only difference that matters.

JSON.parse is all-or-nothing

The built-in parser needs the entire document in memory as a string, then builds the entire object graph, and only then returns. On a large file that is two full copies of your data resident at once, and if the last byte is malformed you get an exception and nothing else — no partial result, no line number you can act on.

There is also a hard ceiling: a single JavaScript string cannot exceed about half a gigabyte of characters in Chrome and Node (V8’s limit; Safari and Firefox draw the line elsewhere). Past that, JSON.parse cannot be reached at all, because the string that would be passed to it cannot exist.

This page does not use JSON.parse. It reads the input as a stream of tokens and emits each record as soon as that record is complete, so memory tracks the size of one record rather than the size of the file, and a syntax error is reported with a position instead of ending the run.

Off the main thread

The parse, the flatten and the write all happen in a Web Worker. That is what keeps the interface responsive — the progress count updates, the preview fills in, and the cancel button works — while a large file is going past.

It is also why there is no upload and no size cap. Nothing about a large conversion costs a server anything, because no server is involved. That is the whole architecture, and the missing limits are a consequence of it.

JSON Lines is easier for everyone

If you are generating the file, write one JSON object per line rather than one enormous array. It is the same data, it is what most log pipelines emit anyway, and it has two practical advantages: a corrupt line can be skipped without losing the rest of the file, and the format is readable by line-oriented tools like head, wc and split.

The streamed JSONL to CSV converter expects that shape. It also reads concatenated JSON with no newlines between the objects, and pretty-printed objects spread across many lines, because the parser tracks structure rather than counting lines.

Settings that matter at scale

Full column discovery costs a second pass. Scanning a sample is faster, but a key that first appears in record 40,000 will not be in the header. On a large irregular file, run the full scan — a slow conversion beats a missing column.

One row per array item multiplies your rows. A million records each holding a ten-item array is ten million output rows. Two arrays in one record multiply against each other. Check the row count before you commit to it.

Excel has a hard row cap. A worksheet holds 1,048,576 rows and 16,384 columns. That is Excel, not this page; if the export is larger, CSV is the only sensible target. You will be told the count rather than handed a silently truncated file.

A skipped-line count is not a failure. Log exports routinely end mid-record because the file was copied while it was being written. Bad records are reported with their line numbers and skipped, and the count is shown with the result. A truncated final line is not a reason to discard the other million.

What still has a ceiling

Your machine. The output has to be assembled into something the browser can hand to a download, and that consumes memory proportional to the result — so a multi-gigabyte output on a laptop with little free RAM can still fail.

When it does, it fails visibly rather than producing a half file. The usual remedies are to narrow the column set first, or to split the input and convert it in parts.