JSON to SQL Insert
Turn a JSON array of objects into INSERT statements you can run in MySQL, MariaDB, PostgreSQL, SQLite or SQL Server. Every object becomes a row, the union of all keys becomes the column list, values are quoted and escaped the way each database requires, rows are grouped into multi-row INSERTs, and an optional CREATE TABLE with inferred column types and a transaction wrapper make the script ready to run.
- Runs in your browser
- No sign-up
- Free to use
How to use JSON to SQL Insert
- Paste a JSON array of objects.
- Choose the database and table name.
- Pick the batch size and whether to add CREATE TABLE and a transaction.
- Copy the SQL or download insert.sql and run it.
JSON to SQL Insert features
Four dialects
MySQL/MariaDB, PostgreSQL, SQLite and SQL Server quoting and types.
Correct escaping
Quotes doubled, backslashes handled for MySQL, N'…' strings for SQL Server.
Batching
One row per INSERT or up to 1,000 rows per statement within each database’s limits.
CREATE TABLE
Inferred types, NOT NULL and an id primary key when the data supports it.
Nested data
Stored as JSON text, or flattened into prefixed columns.
Local
Runs in your browser; the data is not uploaded.
When to use JSON to SQL Insert
- Loading API data or a JSON export into a database.
- Creating seed data for development and tests.
- Moving records between systems that only share JSON.
- Preparing a quick table for ad-hoc SQL analysis.
JSON to SQL Insert FAQ
How are missing keys handled?
The column list is the union of keys across all objects. A key missing from an object is inserted as NULL for that row.
Why do MySQL strings double backslashes?
In MySQL’s default mode, a backslash in a string literal starts an escape sequence. Doubling it stores the backslash itself. PostgreSQL, SQLite and SQL Server treat backslashes literally.
What happens to nested objects and arrays?
They are stored as JSON text, in a JSON, JSONB or text column. Tick “Flatten nested objects” to turn {"address": {"city": …}} into an address_city column instead.
Is it safe to run the output?
The values are escaped as literals, so the statements cannot break out of strings. Still review generated scripts before running them on important databases, and use transactions.
Should my application build SQL like this?
No. Applications should use prepared statements with bound parameters. Generated INSERT scripts are for loading data, seeding and migrations.
How large can the input be?
Up to 50,000 rows at a time in the browser. For bigger loads, use the database’s bulk import tools such as LOAD DATA, COPY or bcp.
From JSON records to SQL rows
JSON arrays of objects are the most common way data leaves web systems: API responses, exports and logs all use them. Relational databases expect rows and columns instead. Converting one into the other means choosing columns, writing every value as a SQL literal with the right quoting, and producing statements in the syntax of the target database. This tool automates each step.
Columns come from the keys of all objects, in the order they first appear, so records with extra or missing fields still line up; absent values become NULL. Identifiers are quoted in each dialect’s style, with backticks for MySQL, double quotes for PostgreSQL and SQLite, and square brackets for SQL Server, so names that clash with reserved words still work.
Escaping is where hand-written scripts usually fail. Single quotes inside strings must be doubled in every database, and MySQL additionally treats backslashes as escape characters in its default mode, so they are doubled too. SQL Server strings are prefixed with N to keep non-English characters intact. Booleans, numbers, nulls and dates are written in each database’s native form.
Grouping many rows into one INSERT statement makes loading much faster than one statement per row, but databases limit the size of a VALUES list; SQL Server, for example, accepts at most 1,000 rows. The batch size respects those limits, and wrapping everything in a transaction means a failure part-way through leaves the table unchanged.
The optional CREATE TABLE statement is inferred from the values: integers become INT or BIGINT by range, decimals floating-point types, ISO timestamps date-time types, and strings VARCHAR sized from the longest value or TEXT. Columns that are never null get NOT NULL, and a unique integer id becomes the primary key. Treat it as a starting point and adjust types and indexes for production use.