JSON vs NDJSON vs GZIP: prepare logs you can restore

Arrays and line-delimited records serve different tasks

A JSON array holds records inside one complete document. NDJSON places a complete JSON value on each line. Choose based on what the recipient accepts and how you intend to inspect the records.

Saving an indented, multiline object with an .ndjson extension does not turn it into line-delimited records. Neatbo parses the selected structure; invalid lines need correction first.

Confirm record boundaries before compressing

A consistent extension matters less than recovering the same records after conversion. Compare counts, first and last records, and examples containing nested data.

Pay attention to timestamps, stack traces and line breaks in messages. Escaped newlines inside text differ from real line separators, so counting visible lines can misrepresent the number of records.

GZIP reduces size, not access

GZIP is compression rather than password protection or encryption. Anyone with the file can decompress it; remove tokens, personal information and internal addresses before sharing.

Compression is not guaranteed to reduce size, particularly for short or already compressed inputs. Compare actual sizes before adding another layer to the handoff.

An archive is useful only if it can be restored

Decompress a copy and inspect the text, record count and representative fields. A successful download alone does not prove that a downstream parser can read it.

Browser tools have memory and input limits, making them suitable for bounded local tasks. Keep the originals; if an input exceeds the tool limits, use a processing method suited to its size rather than changing its extension.

Two records, one newline inside a message

The escaped sequence in the first message belongs to a string. In NDJSON it must remain escaped so the entire record occupies one physical line. A pretty-printed object spanning several lines is JSON, but it is not one-record-per-line NDJSON.

After converting to NDJSON, check that you still have two records and that parsing the first message restores its newline. After GZIP compression, decompress a copy and repeat those checks. This verifies structure and restorability; it does not prove that a downstream logging service accepts your chosen fields.

For large operational logs, browser memory and tool limits may be the wrong fit. Split or process them using an environment suited to their size and access controls. Do not evade the limit by renaming a file or assume compression makes a large decoded dataset cheap to handle.

{"id":1,"message":"first\nsecond"}
{"id":2,"message":"done"}

Before you finish

• Compare record count and selected identifiers.
• Check nested objects and strings containing newline escapes.
• Remove tokens and unnecessary personal data before sharing.
• Keep the original until the recipient confirms successful parsing.

Tools used in this article