Find Malformed JSONL & NDJSON Records

Find an invalid line without losing the following records

1. Download the synthetic fixture below, then open JSONL Viewer and choose that local file. Alternatively, use Open example in tool to load the same reviewed example.
2. Wait for indexing: there are four records, with three valid JSON values and one malformed record.
3. Open Filters, then Advanced evidence filters. Set JSON validity to Malformed only, choose Apply advanced filters, then close Filters. Only record 2 should match.
4. Select that record to inspect its parsing error. Its status key has no value; this example does not automatically repair it.
5. Close record details and choose Show all. Inspect record 3 after the error and record 4, whose value is null. One bad line has not stopped indexing the rest of the file.

Expected results

The complete input contains four records. Record 2 is malformed; records 1, 3 and 4 are valid. A null root is valid JSON, not a missing record. Record 3 retains the source identifier 9007199254740993123, which is larger than JavaScript's safe integer range.

Data Demon Systems maintains this deliberately malformed fixture and tests its validity filters, post-error inspection and valid-only export. The reviewed example link decodes to the same bytes as the download.

Export valid JSONL rows and verify the result

1. Open Filters → Advanced evidence filters, choose Valid only in JSON validity, and select Apply advanced filters. There should be three matches. Close Filters before continuing.
2. Select Export…. For this synthetic fixture, leave every redaction category unchecked; this is a validity filter, not a sanitization task.
3. Select Preview export, check that the preview reports three matching records, then choose Confirm and export and accept the confirmation.
4. Reopen the downloaded .jsonl file in the viewer. It must contain three valid records and no malformed records: the ready object, the object after the error, and null.
5. Check the downloaded source text for the unchanged identifier 9007199254740993123. Unchanged records are copied byte-for-byte; coercing that identifier to a JavaScript Number in another program can lose precision.

Filtering excludes record 2 from the new derivative; it does not delete or fix anything in the original file. Keep the original when you need to investigate the rejected record.

JSONL and NDJSON validation rules

This workflow uses UTF-8 text with one complete JSON value per line. Objects, arrays, strings, numbers, booleans and null are valid roots. A physical newline within a JSON string must be escaped as \n; pretty-printed multi-line JSON is not this record format.

See the JSON Lines format documentation, NDJSON specification and JSON grammar in RFC 8259. This viewer accepts .jsonl and .ndjson for the same line-oriented workflow; it is not a JSON Schema validator.

Limits and safe review

Files are limited to 4 GiB and paste input to 10 MiB. Streaming uses 1 MiB chunks with bounded inspection; supporting browsers can stream exports to a file handle, while the fallback Blob download is capped at 100 MB. Four records test correctness, not large-file throughput.

The versioned JSONL evidence and methodology describe those boundaries. Syntax validity does not establish that data is accurate or safe to publish. Real records may contain sensitive information: choose redactions explicitly, review the derivative and do not treat a clean detector result as proof that every secret was found.

For delimited tables, continue with the CSV identifier and import-trap example. No data in either example is uploaded automatically.

Complete synthetic fixture

{"id":"001","status":"ready"}
{"id":"002","status":}
{"id":9007199254740993123,"status":"after the error"}
null