JSON to SQL

Turn a JSON array of objects into SQL INSERT statements.

Table Name

JSON Input

or drop a file here

SQL Output

INSERT INTO users (id, name, active) VALUES (1, 'Ada Lovelace', TRUE);
INSERT INTO users (id, name, active) VALUES (2, 'Alan Turing', FALSE);

From JSON to SQL INSERT statements

Paste a JSON array of objects and this tool builds one INSERT INTO statement per object, using the union of all keys as columns. Strings are safely single-quoted (with embedded quotes doubled), numbers and booleans pass through as SQL literals, and missing or null values become NULL. Everything runs locally in your browser — your data never leaves your device.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Turning an API response into INSERT statements for a local database.
Producing seed data from a captured payload.
Generating SQL to review before applying a data change.
Loading a small JSON dataset into a table without an ETL tool.
Creating fixtures that match production shapes.

Frequently Asked Questions

How is nested JSON handled?: This is the core difference from CSV: JSON is hierarchical and SQL tables are flat, so nested objects must be flattened into dotted columns, serialised into a JSON column, or normalised into separate tables. There is no single right answer.
What happens when objects have different keys?: The column set is the union of all keys, and rows missing a key get NULL. That is why a single unusual record can add columns for the whole table — worth checking before generating DDL from a large array.
Should I use a native JSON column instead?: Often yes. Postgres JSONB and MySQL JSON store the document directly and support indexing into it, which preserves structure that flattening destroys. Flatten when you will query columns; keep JSON when the shape varies.
How do JSON types map to SQL types?: Imperfectly. JSON has one number type, so integers and floats are indistinguishable without inspecting values; JSON has no date type, so dates arrive as strings; and JSON's null is not the same as SQL NULL in every engine.
What about large integers?: A real hazard: JSON numbers exceeding 2^53 lose precision when parsed by JavaScript, so a 64-bit ID can arrive already corrupted before any SQL is generated. Such IDs should travel as strings.
How are types chosen for the generated columns?: By inspecting the values, which means a sample where every id happens to be small can produce an INT column that overflows later. Widening the inferred types before running the DDL is usually wise.

Common errors and gotchas

Flattening nested objects arbitrarily, since SQL columns are scalar and JSON is not.
Failing to escape quotes inside string values, which breaks the statement.
Letting objects with differing keys produce statements with mismatched column lists.
Inserting a JavaScript number above 2^53, which has already lost precision before the SQL is written.
Assuming null and missing are the same, where one sets NULL and the other should omit the column.