JSONL FAQ

A text format where each line is one complete, independent JSON value — almost always an object. Nothing wraps the lines: there is no enclosing array and no commas between records. See What is JSONL for the full picture and the specification for the precise rules.

Yes, in every way that matters. Two names for the same idea, from two independent specifications that agree on the essentials. NDJSON vs JSONL covers the small historical differences and why neither affects interoperability.

Yes. Without a trailing newline, concatenating two files joins two records onto one line, and wc -l under-counts by one. Every tool on this site writes one.

No — that is the one rule the format has. A pretty-printed JSON object is not valid JSONL. This is exactly why jq needs -c.

Strictly no; in practice most readers skip them. Skip them when you read, and strip them with the encoding fixer if a strict consumer complains.

No, because JSON does not. If you need annotations, put them in a field. For config files that genuinely need comments, JSONC or TOML are better choices.

No. Records are independent, and heterogeneous files are normal — event logs mix event types constantly. Many consumers expect uniformity though; check with field coverage before assuming.

Technically yes — any JSON value is legal. In practice nearly every tool assumes objects, and a file of bare numbers loses the self-describing property that makes the format useful.

.jsonl is now the more common choice and what the ML ecosystem standardised on. .ndjson is equally valid. .json for a JSONL file is asking for trouble: tools will try to parse it as one document and fail with "Extra data".

application/x-ndjson is the de-facto choice and what most tooling recognises. application/jsonl appears occasionally but is less widely understood. Do not use application/json — clients will try to parse the body as one document.

Yes, and it is one of the format's main uses. Send records as they are produced with chunked transfer encoding; the client parses each line as it arrives. JSONL in JavaScript has the client-side code, including the buffering detail people get wrong.

gzip, usually to .jsonl.gz. Repeated keys make JSONL compress unusually well — 80–90% is typical for logs. Every major tool reads gzipped JSONL directly. Check the ratio for your file before deciding it is too large to move.

Not in the format. Limits come from tools: readers that load the whole file, Go's 64 KB default line limit, upload caps. Streaming readers use constant memory regardless of file size — the tools here handle 1 GB in a browser tab.

jq -c '.[]' array.json, or JSON → JSONL in the browser. The reverse is jq -s '.' or JSONL → JSON.

Yes — that is a headline advantage. Open in append mode and write another line; no rewrite, no seeking to remove a closing bracket. Just make sure the file already ends with a newline.

Not with sort — that sorts lines lexically, which is not the same as sorting records by a field. Use the sorter, or jq -s 'sort_by(.field)[]' for files that fit in memory.

Yes. jq for filtering and reshaping, DuckDB for anything involving aggregation or joins. Our SQL playground runs DuckDB compiled to WebAssembly, so real SQL works in the browser with no setup.

The validator checks JSON syntax per line. For structure — required fields, types, enums — infer a schema with the schema inferrer and enforce it with the schema validator.

Most of the modern data stack: pandas (lines=True), Polars, DuckDB, Spark, BigQuery, Snowflake, ClickHouse, Elasticsearch bulk, Logstash, Vector, Fluent Bit, and every LLM provider's fine-tuning API.

When the data is one document rather than a set of records — use JSON. When it is a flat table destined for a spreadsheet — CSV is friendlier. When it is millions of rows for analytics — Parquet is far smaller and faster. The format comparison covers the trade-offs.

Larger and slower to parse, yes — the keys repeat on every line and JSON parsing costs more than splitting on commas. In exchange you get nested structure, types, and no quoting ambiguity. After gzip the size difference mostly disappears.

Training examples are independent records, which is exactly what the format models. It streams, so a large dataset needs no special handling; it appends, so datasets grow incrementally; and one malformed example can be reported by line number instead of failing the whole file.

No. There is no RFC. jsonlines.org and ndjson.org document the conventions, and the format is stable in practice because it is so simple — the only real rule is one JSON value per line. Our specification page writes down what everyone actually agrees on.

Every tool on this site runs entirely in your browser. There is no upload step and no server component that touches your data — which is the point, since JSONL files are usually logs or training data.

Read What is JSONL, then open the viewer with one of the sample files. Ten minutes of poking at a real file teaches more than any spec.

The validator. It tells you whether the file parses at all and where it does not, which determines everything else you do.