JSON Lines Viewer (JSONL / NDJSON)

Drop the .jsonl or .ndjson file onto this page or paste the lines into the text box, and each line is parsed and listed as its own record straight away. The records table shows the line number, byte offset, JSON type and a 200-character preview for the first 2,000 records, and next to it you get the errors table, notices, the key union and the raw source text. No account, Python script or desktop editor is needed.

No. The JSONL file is read and parsed by JavaScript running in your own browser tab, and its contents are not sent anywhere for processing. The JSON array and CSV conversions are built in the same tab, and the result is given to you as text that you copy or save as a file yourself.

Open this page in Edge, Chrome or Firefox on Windows and choose the .jsonl file; nothing has to be installed, and it works the same way on macOS, Linux and phone browsers. Windows has no default program for .jsonl, so double-clicking usually offers Notepad, which shows the text but cannot tell you which lines are broken JSON or which keys are missing from some records.

The errors table gives the exact line number, the column of the first offending character and the byte offset for every line that failed with JSONL_PARSE_ERROR. That code means the line is not one complete JSON value: a truncated object, a missing comma or quote, single quotes, a trailing comma, or a record pretty-printed over several lines. All other lines still parse. Columns are counted in UTF-16 code units, so an emoji counts as two. If a complete value is followed by more text, such as two objects on one line, the code is JSONL_TRAILING_CONTENT instead.

Both mean the bytes are not UTF-8, which JSON Lines requires. JSONL_UNSUPPORTED_ENCODING appears when the file starts with a UTF-16 or UTF-32 byte order mark, often from PowerShell or some Windows exports, and the file is refused instead of guessed at. JSONL_ENCODING_ERROR marks an individual line with an invalid byte sequence and gives its byte offset; neighbouring lines still load and no replacement characters are inserted. Re-save the file as UTF-8 and open it again; one leading UTF-8 BOM is accepted and reported in the summary.

The viewer accepts up to 25,000,000 bytes (about 25 MB) per file or paste, and up to 4,194,304 bytes (4 MiB) on any one line. A larger input is refused with JSONL_TOO_LARGE from its byte length alone, while an overlong line is reported as JSONL_LINE_TOO_LONG and the other lines still parse. Values may nest 128 levels deep. Up to 500 errors are listed with the remainder counted, the records table shows the first 2,000 records, and the source pane shows up to 500,000 characters.

Yes: when a number's text differs from what a JavaScript double prints, such as 9007199254740993, 1e400 or -0, the original source text is recorded and both conversions write that text. Each case is listed in the notices table with its line and column. Numbers whose value really changes as a double are also counted as precision loss and raise a warning, so you can see which IDs or amounts an ordinary JavaScript program would alter.

Viewing is low-risk because the content is only parsed as data and never executed, but the tool does not scan for malware, secrets or personal data and gives no safety verdict. The remaining risk is in what you do next: in a CSV export, text starting with =, +, - or @ is written unchanged, and Excel or similar programs may run it as a formula. Check data from unknown sources before opening the CSV in a spreadsheet.

Choose CSV under Conversion: columns are the top-level keys in first-seen order, and nested objects or arrays are written as compact JSON in a single cell. A missing key becomes an empty field and an explicit null is written as an unquoted null, while empty strings and the string “null” are quoted so they stay distinct. Fields with commas, quotes, CR or LF are quoted with inner quotes doubled, and rows end with CRLF. Failed lines or non-object records block the conversion unless you choose to omit them; the report then counts every omitted line and lists the first 1,000 line numbers. The table is capped at 10,000,000 cells.

Yes. By default any failed line blocks the JSON array conversion with JSONL_CONVERSION_BLOCKED; if you choose to omit failed lines, the array is produced and the transform report gives the full count of omitted lines and lists their line numbers, up to the first 1,000. Records are written in source order using each line's original text, so number spelling and duplicate keys stay exactly as in the file. The download is named after your file with a .json extension, and output is limited to 64,000,000 characters.

A JSON file holds one value, usually a single large array or object, while JSONL puts one complete JSON value on each line so it can be appended to and read line by line. NDJSON is essentially the same format under another name, and this viewer opens both .jsonl and .ndjson. If you paste a pretty-printed JSON document, nearly every line fails because one value spans many lines; a minified single-line JSON document is read as one record.

No. Zero errors means only that every non-blank line is syntactically valid JSON; no schema, required fields or value rules are checked. The key union and the differing-records count describe only the records that parsed and are always shown alongside the failed and blank line counts. A key missing from some records or a value whose type varies is listed for you to review, not declared invalid, and duplicate keys, lone CR separators and precision loss appear as notices.