What is the difference between NDJSON and JSON Lines?

Almost none. Both are one complete JSON value per line, separated by a newline, in UTF-8. The NDJSON spec also allows CR LF endings and lets a reader skip empty lines; JSON Lines does not mention blank lines, but this tool skips them for both, and reads .ndjson, .jsonl and .ldjson files the same way.

Does converting change my numbers?

No. Most converters parse each record and write it out again, which turns 1.0 into 1, rounds an integer past 2^53 (a 64-bit ID, say), turns \u00e9 into é and silently drops a key given twice. This tool never does that round trip: it works on the text, so only the whitespace between values changes. The two-space and one-line output was checked byte for byte against jq 1.7, which also keeps number literals, on records whose numbers and strings jq leaves alone.

Why is a line reported as bad?

Each line must be one whole JSON value by RFC 8259: double-quoted keys and strings, no trailing commas, no NaN or Infinity, no leading zeros, and tabs or line breaks escaped inside strings. A pretty-printed record spread over several lines is not NDJSON, but it is read as values one after another, and can be written back out one per line.

No. The file is read, checked and converted in your browser, gzip included, and nothing is sent anywhere.

NDJSON / JSON Lines

runs in your browser

Check NDJSON or JSON Lines line by line, turn it into a JSON array or back, reflow pretty-printed records, and see every field — with numbers kept exactly.

Read as

Drop a file here, or .

NDJSON, JSON Lines or a JSON array — .gz too. Read in your browser; nothing is uploaded.

Input

Paste NDJSON, a JSON array, or JSON values one after another.

Output

Write as

Indent

Only records containing

Paste or open some records first.

about this tool

One JSON value a line

NDJSON (newline-delimited JSON) and JSON Lines are the same idea: a file where every line is a complete JSON value, usually an object. Logs, database exports, analytics events and machine-learning datasets use it because a program can read one record at a time without loading the whole file, and append a record without rewriting it. Paste some in, or open a .ndjson, .jsonl or .ldjson file — gzipped ones too, several gzip members joined end to end included — and each line is checked on its own.

A bad line is reported with its line and column and a plain reason: a trailing comma, single quotes, an unquoted key, NaN, a leading zero, a tab left raw inside a string, or, read as NDJSON, two values run together on one line. While any line is bad nothing is written; tick the box to leave the bad lines out and write the rest. Lines holding only spaces or tabs are skipped as blank, as the NDJSON spec allows (JSON Lines does not mention them); a line holding anything else, a no-break space included, is a bad line. CR LF endings are read as LF, a byte-order mark is taken off, and bytes in a file that are not UTF-8 show as �; each of those is noted. Which lines count as valid was checked against Python's json module on a set of edge cases, and against JavaScript's own JSON.parse on those and 6,000 damaged documents.

Converting, without changing a thing

Write the records out as a JSON array — laid out with two or four spaces, or on one line — or as NDJSON again, one minified record a line. A JSON array pasted in goes the other way, into one line per element; "Write as" and "Read as" change either choice. Records that were pretty-printed one after another, or written as RFC 7464 JSON text sequences, are read as a stream of values and written out one per line. In a stream, a bad value is reported and reading picks up again at the next record separator, or at the next line.

None of this goes through JSON.parse and back, which is where data is usually lost: 1.0 would become 1, a 64-bit ID past 2^53 would be rounded, \u00e9 would become é, and a key given twice would quietly keep only its last value. Here each number, string and key is copied exactly as written, and only the whitespace between them changes — along with the record separators, a byte-order mark and CR LF endings, as above. The two-space and one-line output was checked byte for byte against jq 1.7 (jq -s ., jq -s -c ., jq -c . and jq -c '.[]') on records whose numbers and strings jq leaves alone. A key given twice, or an integer too large for JavaScript, is pointed out, since the next program to read the file may not be as careful.

The fields

For records that are objects, the tool lists their top-level keys (the first 200), how many records have each, and what kinds of value it holds — so a field that is a number in most records and a string in a few shows up at once. To filter the output, type text that the records you want contain; the match ignores upper and lower case and is on each record's text as written, so \u00e9 does not match é. For nested values, the JSONPath tester queries a single document, and a JSON to CSV conversion flattens records into columns.

Limits

Files up to 128 MB are read, or 256 MB once unpacked from gzip, and very large ones are shown only in part in the box, though all of it is checked and converted. Nesting deeper than 512 levels is refused. Nothing is uploaded.

questions

What is the difference between NDJSON and JSON Lines?: Almost none. Both are one complete JSON value per line, separated by a newline, in UTF-8. The NDJSON spec also allows CR LF endings and lets a reader skip empty lines; JSON Lines does not mention blank lines, but this tool skips them for both, and reads .ndjson, .jsonl and .ldjson files the same way.
Does converting change my numbers?: No. Most converters parse each record and write it out again, which turns 1.0 into 1, rounds an integer past 2^53 (a 64-bit ID, say), turns \u00e9 into é and silently drops a key given twice. This tool never does that round trip: it works on the text, so only the whitespace between values changes. The two-space and one-line output was checked byte for byte against jq 1.7, which also keeps number literals, on records whose numbers and strings jq leaves alone.
Why is a line reported as bad?: Each line must be one whole JSON value by RFC 8259: double-quoted keys and strings, no trailing commas, no NaN or Infinity, no leading zeros, and tabs or line breaks escaped inside strings. A pretty-printed record spread over several lines is not NDJSON, but it is read as values one after another, and can be written back out one per line.
Is my file uploaded?: No. The file is read, checked and converted in your browser, gzip included, and nothing is sent anywhere.