How this tool fits your workflow
JSONL versus a JSON array
Both represent a list of records. The difference is entirely in how the text is laid out, and that difference determines how you can process the file.
| JSON array | JSONL / NDJSON | |
|---|---|---|
| Wrapping brackets | Yes, [ ... ] | None |
| Separator | Commas | Newlines |
| Append a record | Rewrite the file | Append one line |
| Read without full parse | No | Yes, line by line |
| One corrupt record | Whole file fails | Only that line fails |
| Human readable diff | Poor | Good — one record per line |
Worked example: a training dataset
LLM fine-tuning datasets are almost always JSONL, because they are large and are appended to incrementally. A three-record file looks like this in JSONL:
- Paste the JSONL into the left pane with JSONL → JSON array selected.
- The right pane shows a formatted array of three objects, indented for reading.
- If line 2 has a missing brace, you get "Line 2 is not valid JSON" plus the start of that line, rather than a generic parse failure.
- Switch direction to turn an array back into JSONL — useful when a tool exported an array but your pipeline expects one record per line.
- OpenAI and most fine-tuning APIs require JSONL for training files.
- Structured application logs are usually JSONL so each line can be shipped independently.
- BigQuery, Snowflake and Athena all ingest newline-delimited JSON natively.
- Kubernetes and Docker container logs are JSONL when structured logging is enabled.
Common mistakes
- Pretty-printing JSONL. Each record must be on exactly one line. Formatting a JSONL file with indentation breaks it, because a record spanning several lines is no longer parseable line by line.
- Adding commas between lines. There are none in JSONL. A trailing comma makes each line invalid JSON.
- Wrapping the whole thing in brackets and calling it JSONL. That is a JSON array, and a JSONL reader will fail on the first line.
- Assuming every record has the same shape. JSONL makes no such guarantee — records are independent, and heterogeneous records are legal and common in logs.
- Using a text editor that strips the trailing newline. Some tools require the file to end with one; most tolerate either.
When not to use this
Related workflow
Once you have a JSON array, the JSON formatter validates and reformats it, and the JSON Schema generator can infer a schema so you can check whether your records really are consistent.
For records that need to reach a spreadsheet, the CSV and JSON converter turns an array of flat objects into columns. If the records are nested, flatten them first with the JSON flattener.
When you need TypeScript types for the records, paste one into the JSON to TypeScript converter.
Frequently asked questions
- What is JSONL?
- JSON Lines is a format where each line is a complete, independent JSON value. There are no commas between records and no wrapping array brackets. NDJSON is the same idea under a different name.
- Why is it used for logs and datasets?
- Because you can append a record by writing one line, and read records one at a time without parsing the whole file. A 50 GB JSONL file streams line by line; a 50 GB JSON array has to be parsed in full before you can read the first record.
- What if one line is malformed?
- The converter stops and reports the line number along with the start of that line, so you can find it in your source file. This is the main practical advantage over pasting into a general JSON parser, which cannot tell you which record failed.
- Does it handle blank lines?
- Yes, blank lines are skipped rather than treated as errors. Trailing newlines at the end of a file are common and harmless.
- Is JSONL the same as a JSON array?
- They hold the same data but are not interchangeable as text. A JSON parser will reject raw JSONL because of the missing brackets and commas, which is why converting is necessary.