How-to guide

How to Convert JSON to SQL

To convert JSON to SQL, paste an array of objects into a converter and name the target table. Each object becomes a row and each key becomes a column. Quote every identifier so reserved words such as order do not break the statement, and read the output before running it — generated SQL escapes values but does not parameterise them.

JSON to SQL Converter

Turn a JSON array into INSERT statements.

Open the tool

This is a common job when seeding a development database, loading a small reference table, or moving a handful of records between systems. The conversion itself is mechanical; almost all the difficulty is in three details that produce SQL which looks right and is not.

Those are: reserved words used as field names, records that do not all carry the same fields, and nested values that have no column type. Each has a correct answer, and getting any of them wrong fails loudly at best and corrupts data quietly at worst.

Step by step

  1. Start from an array of objects

    Each object becomes one row and its keys become columns. A bare object is treated as a single row; an array of arrays has no field names and cannot be converted.

  2. Name the table and pick the quoting style

    MySQL and MariaDB use `backticks`, PostgreSQL and standard SQL use "double quotes", SQL Server uses [brackets]. Using the wrong style is a syntax error, not a stylistic difference.

  3. Let every identifier be quoted

    order, group, key, user and desc are all reserved words and all common field names. Quoting only the identifiers that look unusual leaves those bare and the statement fails. Quoting everything is never wrong.

  4. Check the column list

    When records carry different fields, the column list should be the union of all of them, with NULL filling the gaps. If your converter uses only the first record's keys, later records silently lose data.

  5. Decide what to do with nested values

    An object or array has no column type. Storing it as JSON text is the honest default; if you need the values as columns, flatten the document before converting.

  6. Read the SQL before running it

    Generated SQL escapes quotes but is not parameterised. Treat it as a script to review, run it against a development database first, and never paste untrusted data through it into production.

Example

Note the quoted "order" — a reserved word — and the NULL filling the field the first record lacks.

JSON

[
  { "id": 1, "order": 10 },
  { "id": 2, "order": 20, "note": "late" }
]

SQL

INSERT INTO "orders" ("id", "order", "note") VALUES
(1, 10, NULL),
(2, 20, 'late');

Frequently asked questions

Why must identifiers be quoted?
Because reserved words are extremely common as field names. A column called order, group, key or user is a syntax error unquoted, and the failure often appears only when you reach the one record that uses it. Quoting everything costs nothing.
What if my records have different fields?
The column list should be the union of every record's keys, with NULL where a record lacks one. A converter that reads only the first record produces statements that are either misaligned or missing data.
Is generated SQL safe to run?
It is safe to read. Escaping quotes correctly stops well-formed data breaking the statement, but generated SQL is not the same as a parameterised query. Review it, run it somewhere disposable first, and use parameter binding in application code.
Why is there no CREATE TABLE?
Because column types cannot be inferred safely from one sample. JSON cannot distinguish a product code that happens to be digits from a number, and guessing wrong turns 007 into 7. Write the schema deliberately.
How do I handle dates?
JSON has no date type, so dates arrive as strings and are inserted as strings. Most databases cast them if the format matches the column — ISO 8601 is the safest choice. Otherwise convert the column explicitly in the INSERT.

Tools used in this guide

All tools →
All guides →

Last reviewed .