JSON vs JSON Lines is a shape question. JSON is exactly one value: an object, an array, or a primitive. JSON Lines (NDJSON) is a text file where each non-empty line is its own JSON value. You can convert a JSON array to JSON Lines and back. You cannot honestly turn a single object into “lines” without wrapping it, and you cannot paste a pretty-printed array into a line-oriented parser and expect one record per object.
People name both files .json and then argue with the parser. The parser is answering a different question than the filename.
A JSON array is one value. It can hold objects, nested arrays, and mixed types. You format it, validate it, or minify it as a whole. The JSON Formatter pretty-prints that one value. A pretty-printed array uses newlines inside the value. Those newlines are not record separators.
If you need random access to item 17, an array (or a real database) is the right shape. If you need to append a record without rewriting the file, an array is the wrong shape: you must parse the whole document to insert before the closing ].
JSON Lines is for streams and logs. Each line is typically one event. A process can append a line. A reader can stop at the first bad line and tell you the line number. The JSON Lines to JSON converter on this site builds an array from those lines, or writes compact JSON per line from an array. Empty lines are skipped. A root object is refused for JSON → JSON Lines, because that object is one value, not a list of records.
Pretty-printed objects across several lines are not JSON Lines. If a log pretty-printed a payload, you do not have NDJSON. You have broken line protocol.
Skipping blank lines is practical. Inventing a value for a blank line is not. A line that is not JSON should fail with a line number. Converting the rest and hiding the bad line is how logs lose events.
Types stay JSON types. A line that is the string "true" is not the boolean true. After you have an array, you can format it or walk it. Before that, you have lines.
If the records are flat objects and someone needs a spreadsheet, JSON Lines is still JSON. The JSON to CSV Converter wants an array of objects (or CSV with headers). Nested values stay as JSON text in cells. That is a third shape, not a better JSON Lines. The longer comparison is JSON vs CSV. Choose CSV when the consumer is a sheet. Choose JSON Lines when the consumer is a log pipeline.
JSON vs JSON Lines is one value versus one value per line. Convert arrays to NDJSON. Do not convert a lone object and call it a log. Do not treat indentation newlines as record boundaries. If you need columns, that is CSV, with the nested-cell limit stated up front.
A log shipper that writes one event per line can survive a truncated last line: you drop the incomplete record and keep the rest. A truncated JSON array is usually one broken document. That operational difference is why services emit NDJSON even when the “logical” payload is a list.
After conversion to an array you can format, sort keys, or diff two snapshots. Those jobs need one JSON value. Do them after you have left the line protocol, not on a file that still contains record separators.
If a producer emits one pretty-printed object across twenty lines, ask for compact JSON per line. Repairing that file by hand is not a converter’s job. JSON vs JSON Lines only stays clean when each line is already a complete value.
Not usefully. JSON Lines expects one value per line. A single object is one value. Convert a JSON array, or wrap records first.
No. Pretty-print inserts newlines inside one value. JSON Lines uses one complete JSON value per line, usually compact.
A converter should skip them. A line that contains illegal JSON should fail and name the line.
When the consumer is a spreadsheet and the records are objects. Nested fields will not become extra columns on this site.
