JSONL Validator

Validate newline-delimited JSON line by line, and see exactly which lines fail and why.

Runs on your deviceDeveloperWorkingNo account needed

What this tool does

JSONL Validator treats each line of your input as a separate JSON document. It splits on line breaks, parses every line with a strict scanner, and carries on to the next one rather than stopping at the first failure — which is the whole point of the format, and the reason one corrupt line in a 40,000-line export should not cost you the other 39,999. Each failure is listed by its line number and a plain-language reason; a syntax failure adds the column where the scan gave up, while a line that parsed cleanly but holds the wrong kind of value is named without one.

The default rule is that every line must be a JSON object, because that is what log files and NDJSON datasets almost always hold; a bare array, number or string sitting on its own line is reported as the wrong shape instead of quietly accepted. Alongside the failures the report prints a key census — the property names found across the valid lines, ordered by how often each occurs, up to forty of them. A field present on 9,998 lines out of 10,000 is usually the interesting one.

Two of the three output modes rewrite rather than report. The valid lines, re-serialised drops the failures and prints what survived as one compact JSON value per line; a single pretty JSON array gathers the same values into one indented document you can paste into JSON Formatter or a diff. Both go through a parse and a re-serialise, so spacing and number formatting are normalised, a property repeated inside a single line collapses to its last value, and an integer beyond the precision of a 64-bit float comes back rounded. An export full of nineteen-digit identifiers is safer read as a report than rewritten here.

The work happens in this browser tab, so nothing is uploaded and a production log carrying customer identifiers stays on your machine. The edges are worth knowing first. Input is pasted into a text box — there is no file picker — and the whole document is held in memory, so a multi-gigabyte log wants a slice rather than the lot. Only the first error on each line is reported, because the scan stops where that line stops making sense. The failure table lists the first 200 and counts the rest. It judges syntax and shape, not meaning: a line with entirely the wrong field names is valid JSON and passes.

How to use it

  1. Paste the lines. Drop your JSONL into the input box, or press Load sample for four lines where two are deliberately broken — one carries a trailing comma, the other a missing one. For a large log, paste a slice rather than the whole file.
  2. Decide whether every line must be an object. Left on, a line holding an array, a number or a string is flagged with the type it actually found. Switch it off for a file that legitimately mixes shapes.
  3. Choose how blank lines are treated. Ignored by default. Turn that off to have empty lines reported as problems — a trailing newline at the end of the file is never counted against you.
  4. Choose the output, then run it. Validation report gives the failure table and the key census; the other two modes return the surviving lines, either one per line or as one array. Copy output takes the plain-text list of failures when you are on the report.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

A log shipper rejecting a batch

Ingest pipelines usually reject the whole batch and name neither the line nor the reason. Pasting the batch here gives you both, for every bad line at once.

Checking a dataset before an import

Machine-learning and analytics tooling reads JSONL, and one malformed record can abort a long import. Validating the file first is cheaper than watching it fail at record 800,000.

Reading an unfamiliar dump

The key census shows which fields exist and how consistently, so you can see the shape of someone else's export without opening it in an editor.

Salvaging a truncated file

A log cut off mid-write leaves a broken final line. The re-serialised output keeps everything that parsed and drops what did not, with a count of how many were dropped.

Moving a sample into a JSON tool

Most formatters and diff tools expect one document, not many. The array output turns a handful of lines into a single JSON value you can paste straight in.

Questions

Is my data uploaded?
No. Parsing happens in this browser tab, so nothing is transmitted, logged or stored, and once the page has loaded, running it makes no network request at all. The page itself is not cached for offline use, so a cold start still needs a connection.
What is the difference between JSONL, NDJSON and JSON Lines?
Nothing that matters here — they are three names for the same convention of one JSON value per line, and this tool reads all three. A conventional JSON array spread across many lines is a different thing; use JSON Validator for that.
Why is a line rejected that my code accepts?
The scan is strict JSON, so trailing commas, comments, single-quoted strings, unquoted keys, NaN and Infinity are all rejected even though several parsers tolerate them. The wording varies: a single-quoted value and a negative Infinity are called out by name, but most reasons simply report the character the scan stopped on, and a bare NaN or Infinity comes back as an unexpected letter rather than as itself.
Does it report every problem on a line?
One per line. The scanner stops where the line stops being interpretable, since everything after an unclosed bracket is guesswork, but each line is scanned independently so a whole file's worth of first errors comes back in a single pass.
How large a file can it take?
There is no imposed limit, but input is pasted rather than opened from disk and the whole document sits in memory. It yields to the browser every 500 lines so the tab stays responsive; even so, a very large log is better sampled with head or split.
Does it check the fields against a schema?
No. It verifies that each line parses and, optionally, that each line is an object. Anything about required properties, permitted values or the type a field should hold is a job for a JSON Schema validator, and this is not one.
Are duplicate keys inside a line reported?
Not by this tool. The line is still valid JSON and passes, and in the rewriting output modes only the last value of a repeated property survives. JSON Validator lists duplicates by path and line if that is what you are chasing.
Does it repair broken lines?
No. Nothing is guessed or patched. The rewriting modes drop lines that failed and tell you how many went, so anything you have to keep must be fixed by hand.
What counts as a blank line?
A line with nothing but whitespace. Line numbers are always counted from the file you pasted, so they still line up after blanks have been skipped. One wrinkle if you switch the setting off: blank lines are then listed as failures but are still left out of the line total the heading counts against, so a mostly-empty file can report more failures than it says it has lines.

Related tools