JSON to SQL INSERT

This converter writes SQL INSERT statements from a JSON array of records in your browser. Column names are quoted with double quotes, strings are escaped by doubling single quotes, null becomes NULL, and booleans become TRUE or FALSE. The records must share one key set; nothing leaves the tab.

Local-only

Input0 charsOutput

Seed data lives in JSON — API fixtures, exported reports, test records — but the database wants INSERT statements. The crossing is mechanical and worth doing precisely: each record becomes one row, each key becomes a column, and each value has to arrive as a correctly typed SQL literal. Get the escaping wrong and the statement fails immediately; get it subtly wrong and it fails three weeks later, on the first name with an apostrophe in it.

This converter emits multi-row INSERT statements: one double-quoted column list, then a VALUES tuple per record. Double quotes are the SQL standard for identifiers, and single-quoted strings have any embedded quote doubled — the O''Brien form every conforming parser reads as one literal quote. Numbers stay bare, true and false become TRUE and FALSE, and JSON null becomes the unquoted keyword NULL. You name the target table in the tool's table field; the example below uses people.

All of it happens in this browser tab. Your records are parsed with the browser's own JSON.parse, the SQL text is assembled in memory, and no request leaves the page — DevTools' Network panel shows nothing during a conversion, and the site's Content-Security-Policy forbids outbound connections in any case.

If your rows are in a spreadsheet export rather than JSON, the CSV to SQL converter applies the same quoting rules on top of an RFC 4180 parser with per-cell type inference.

The converter only accepts a strict JSON array, so if the payload came from a script or a log file, check it with the JSON validator first; the error you see there is the error this tool would raise.

How the conversion actually works

The engine parses your JSON with JSON.parse — the browser's own RFC 8259 parser — and then makes three checks before emitting anything, because each failure mode produces SQL that is either invalid or quietly wrong:

Shape: the top level must be an array whose every element is an object; a bare object or a nested array is refused with a message naming the offending index.
Consistent keys: every record must have the same key set. An INSERT statement declares one column list, so a record carrying a key the others lack has nowhere to go — the converter reports the key and the row instead of inventing NULLs you did not ask for.
Flat values: objects and arrays nested inside a record have no plain SQL literal equivalent, so they are refused with the path named, rather than stringified behind your back.

The literal mapping

Each value is rendered by its JSON type, using only standard SQL forms:

One typing note deserves its own line: TRUE and FALSE are standard SQL boolean literals, read natively by PostgreSQL and SQLite and read as 1 and 0 by MySQL. Engines without boolean literals — SQL Server's BIT columns, for instance — want 1 and 0 in the statement instead, so for those targets replace the keywords; the quoting and NULL rules stay exactly the same.

JSON value	SQL literal
"Ada Lovelace"	'Ada Lovelace'
"O'Brien"	'O''Brien' — the quote is doubled
null	NULL, unquoted
true / false	TRUE / FALSE
9.5	9.5, a bare number
[1, 2]	Refused, with the path named

What the output looks like

The worked example below is the exact pair the converter's Load sample button produces for a table named people: two records, four consistent keys, and one of each interesting literal. The second record's name contains an apostrophe, and the output shows the standard defence — the quote is doubled, which every SQL dialect reads as a single literal quote rather than the end of the string. Its score is null and lands as the keyword NULL, not an empty string — the difference between a missing measurement and a zero-length one. Copy the block as-is or download it as a .sql file; either way it is a complete, terminated script.

Getting the statements into your database

The output is a complete, terminated script: paste it into a SQL console, or save it as a .sql file for a migration runner. For a clean load, wrap it in a transaction — BEGIN; before, COMMIT; after — so a mid-script failure rolls back the whole seed instead of leaving half a table behind. Because the statements use only standard SQL forms, the same file runs unchanged on PostgreSQL, SQLite and MySQL with ANSI_QUOTES enabled; only the boolean note above ever needs touching for a specific engine.

psql: paste into the interactive shell, or run \i seed.sql from the prompt.
sqlite3: run .read seed.sql, or pipe the file in from your shell.
GUI tools: most query windows accept the whole script as one batch and report the row count.

Frequently asked questions

Does the JSON to SQL converter upload my data?

No. Parsing and SQL generation run in this browser tab with JavaScript loaded once at page open. The page has no endpoint to post data to, and its Content-Security-Policy blocks outbound requests. The claim is verifiable: open DevTools, switch to the Network panel, convert a large file, and watch no request appear.

Why are column names wrapped in double quotes?

Double-quoted identifiers are the SQL standard, and they are what protects column names that collide with keywords or mix case — a column named order or UserName needs quoting to survive. PostgreSQL, SQLite and SQL Server accept them directly; MySQL does too when ANSI_QUOTES mode is on, otherwise use its backtick equivalent.

How are single quotes inside strings escaped?

By doubling them, which is the standard: the name O'Brien is emitted as 'O''Brien', and every conforming parser reads the pair as one literal quote. Backslash escaping — as in O\'Brien — is a MySQL extension and produces a syntax error or a stray backslash everywhere else, which is why this converter does not emit it.

What does JSON null become in the SQL?

The unquoted keyword NULL — SQL's own marker for an absent value, distinct from the empty string ''. A null score means no measurement was taken; an empty string means a measurement of zero length. The converter preserves that distinction, because collapsing the two is one of the harder mistakes to undo in a populated table.

Why must every record have the same keys?

Because an INSERT statement declares its column list once, and every VALUES tuple must fill exactly those columns. A record missing a key, or carrying an extra one, has no defined place in that list. The converter reports the offending key and row index so you can normalise the records first — deliberately filling gaps with null if that is what you intend.

Why one multi-row INSERT instead of a statement per row?

Fewer statements, one parse, and typically a much faster load — a single multi-row INSERT is the shape most bulk-loading guides recommend for seeding. The output ends with a semicolon so it is a complete script, and if your tooling prefers one statement per row, each VALUES tuple sits on its own line, so splitting is a small mechanical edit.

ToolsByUs team · How we check our tools