SQL to JSON Lines Converter
Get a dump into a warehouse. One compact JSON object per line, no wrapping array, and a key that is a string on the first line is a string on the millionth.
To convert SQL to JSON Lines, paste your INSERT statements above. Each row becomes one compact JSON object on its own line, with no wrapping array and no commas between records. Types are decided once per column so the file passes a schema check, which is what BigQuery, Snowflake, Redshift and DuckDB all require of an NDJSON load.
Need to filter rows before the load? Open the app
The format loaders actually want
A bulk load into BigQuery, Snowflake, Redshift or DuckDB does not want a JSON document. It wants newline-delimited JSON: one object per line, no array brackets, no commas between records.
The reason is streaming. A wrapping array has to be parsed as one value, which means the whole document has to be held in memory before any of it can be processed. Newline-delimited records can be split by line and handled one at a time, forever, which is why every log shipper and every warehouse loader converged on the same shape.
It is also the reason a broken NDJSON file fails in such an annoying way: the loader gets three million rows in before it hits the one line whose schema disagrees, and then rolls the whole thing back.
The bug this page exists to not have
An audit of the leading free converter on this exact term found its NDJSON output doing this, from a single input file:
{"id":2,"zip":94043,"amount":80}
{"id":1,"zip":"01730","amount":"120.50"}
The zip key is a number on one line and a string on the next. So is amount. Every consumer named on that converter's own page will reject this: BigQuery raises a schema mismatch, Snowflake fails the COPY, a typed log pipeline drops the record. Their sibling page for plain JSON gets it right, which means one emitter simply skipped the profiling step.
Here there is one typing decision, made once from the whole column, before any writer sees the table. Every target on this site shares it, so the JSON Lines file agrees with the JSON file, the CSV, the Parquet and the workbook.
Worked example
Four rows, with the two columns that catch converters out:
INSERT INTO orders (order_id, region_code, units, revenue, paid, placed_on) VALUES
(4101, '01', 12, 1840.50, TRUE, '2026-01-08'),
(4103, '10', 40, 6120.75, FALSE, '2026-01-11');
And the JSON Lines:
{"order_id":4101,"region_code":"01","units":12,"revenue":"1840.50","paid":true,"placed_on":"2026-01-08"}
{"order_id":4103,"region_code":"10","units":40,"revenue":"6120.75","paid":false,"placed_on":"2026-01-11"}
region_code is a string on both lines even though 10 on its own would pass as a number, because the column contains 01 and the column decides together. revenue is a string because 1840.50 does not round trip through a double. placed_on is a string, which is correct: a warehouse will parse it into a DATE using the column type you declare, and inventing a timestamp here would only add a timezone you did not choose.
Practical notes for a real load
- Declare your schema, do not autodetect it. Autodetection samples the first few hundred lines, and a column that is null for the first thousand rows gets typed from row 1001. Write the schema from the columns you can see in the preview here.
- A padded code belongs in a STRING column. If your target declares
region_codeas an integer, the load succeeds and the zeros are gone. This file gives you the right value; the schema has to accept it. - Empty means null. A SQL NULL becomes a JSON
null, not an empty string and not a missing key. Every object carries every key, which keeps a fixed-schema load happy. - One table per file. A dump with several tables gives you a picker. Load them separately; a single NDJSON file holding two shapes is not something any loader can use.
- Nothing is uploaded. The conversion runs in your tab, which matters when the file is a production dump.
Lines or an array
If you actually wanted a single JSON document rather than one object per line, the sibling page for that is one click away and runs the same typing, so switching between them changes only the punctuation.
The rule of thumb: an array for anything a person or an API will read, lines for anything a loader will consume. The moment the row count passes what you would open in an editor, lines is the right answer.
Frequently Asked Questions
What is the difference between JSON Lines and NDJSON?
Nothing that matters. They are two names for the same convention, one JSON value per line separated by newlines. The .jsonl and .ndjson extensions are both in use and every tool that reads one reads the other.
Will this file load into BigQuery or Snowflake without a schema error?
That is the whole point of the typing rule. Each column is given one type from all of its values, so a key is never a number on one line and a string on the next. Declare the schema rather than letting the loader autodetect it, since autodetection samples only the first few hundred lines.
Why is my amount column quoted?
Because a value in it does not survive as a JSON number. 1840.50 written back is 1840.5, so the column stays text and keeps the exact figure. If you want it numeric, cast it in the query before you dump, or let the warehouse cast the string on load.
Are keys present on every line even when the value is null?
Yes. Every object carries every column, with null where the database had NULL. A missing key and a null value mean different things to a fixed-schema loader, and only one of them is what your data says.
Is there a row limit?
No row cap. The widget takes files up to 100 MB and the full editor streams considerably more. Nothing is uploaded at any size, which is usually the deciding factor when the input is a production dump.
Can I get a single JSON array instead?
Yes, the sibling SQL to JSON page emits one, with the same typing decisions behind it. Use an array when a person or an API will read the result and lines when a loader will consume it.
Related
Get the dump ready for the warehouse
One object per line, one type per column, real nulls. No array to hold in memory.
Back to the converter