TSV to JSONL
JSONL — newline-delimited JSON — is what you feed a streaming consumer: BigQuery and Snowflake loaders, Elasticsearch bulk indexing, LLM fine-tuning APIs, and any pipeline that wants to process one record at a time without holding the whole file in memory. It has TSV's line-per-record property and JSON's typing. This converts between them; the reverse is JSONL → TSV.
How to use
- Paste or drop the TSV. The header row supplies the JSON keys, so it needs to be present and sensible — run it through header tools first if the names have spaces or capitals.
- Decide about coercion (see below). Off is the safe default.
- Omit empty fields if the consumer treats a missing key differently from an empty string — Elasticsearch and most schema validators do.
- Download as
.jsonland check the first line before loading a large file anywhere.
Coercion: what it does and what it breaks
With coercion off, every value is a JSON string. That is lossless and boring — "007", "1.10", and "true" all survive exactly as written. With it on, values that look like numbers become numbers, true/false become booleans, and the literal null becomes null.
The failure modes are worth naming because they're silent. A zip code 01234 becomes the number 1234. A version string 1.10 becomes 1.1. A phone number +15551234 stays a string but 15551234567890123456 loses precision past 2⁵³. An ID column of long digit strings is the most common casualty. If any of those exist in your file, leave coercion off and let the consumer's schema do the typing — or coerce, then check the affected columns with value counts.
Why JSONL rather than a JSON array
A JSON array of objects has to be parsed in full before the first record is available, and one malformed byte invalidates the whole document. JSONL degrades gracefully: each line is independent, so a corrupt line costs you one record, files can be appended to without rewriting, and head, tail, split, and grep all work on it. That's why every bulk-load API asks for it. If you actually need the array form, TSV → JSON produces that instead.
FAQ
Can it produce nested objects?
No — output is flat, one key per column. If you need nesting, a header name like address.city comes through as a literal key with a dot in it, which some consumers (including BigQuery with the right schema) will interpret as a path. Otherwise do the nesting in a script after conversion.
Is this the right format for fine-tuning data?
JSONL is the container those APIs expect, but each provider wants a specific object shape — a messages array, or prompt/completion keys. Name your TSV columns to match the required keys and the output will be close; anything involving nested message arrays needs a script.
What happens to tabs and newlines inside fields?
JSON escapes them itself — \t and \n inside the string value — so they round-trip correctly. This is one place where JSONL is strictly better than TSV, since JSON has real escaping and TSV does not.
Is there a size limit?
Browser memory. For files big enough to matter to a bulk loader, jq -R or a short Python script streaming line by line is the better tool — this page is for getting the format right on something you can eyeball.
Privacy
100% client-side. No upload. See the privacy policy. For more JSONL tooling see jsonlkit.com.