"category": "format-converter",
JSON to SQL Converter
"tldr": Paste a JSON array and get a CREATE TABLE statement with inferred column types plus one INSERT per row - ready for SQLite or Postgres.
Turn a JSON array of objects into ready-to-run SQL: a CREATE TABLE statement with column types inferred from your data (INTEGER, REAL, BOOLEAN, TEXT) and one INSERT statement per row. Column names are snake_cased and string values are escaped correctly.
This is the fastest way to get an API export or a JSON dataset into SQLite, Postgres, or MySQL for ad-hoc querying - no import wizards, no intermediate CSV step.
How to convert JSON to SQL
- 1Paste a JSON array of objects; each object becomes one table row.
- 2Column types are inferred from the values across all rows - mixed or text values fall back to TEXT.
- 3Single quotes in strings are escaped by doubling, per the SQL standard.
- 4Copy the output and run it in your database client; rename the "data" table as needed.
Convert JSON to SQL in code
-- paste the generated SQL into the sqlite3 shell
BEGIN;
CREATE TABLE data (...);
INSERT INTO data (...) VALUES (...);
COMMIT;
SELECT name, score FROM data WHERE active = TRUE;import json, sqlite3
rows = json.loads(text)
conn = sqlite3.connect("data.db")
cols = rows[0].keys()
conn.execute(f"CREATE TABLE data ({', '.join(cols)})")
conn.executemany(
f"INSERT INTO data VALUES ({', '.join('?' * len(cols))})",
[tuple(r[c] for c in cols) for r in rows],
)Frequently asked questions
Which SQL dialect does the output target?
The output uses portable ANSI SQL that runs unchanged on SQLite and PostgreSQL. For MySQL, BOOLEAN maps to TINYINT(1) automatically. Dialect-specific tuning (SERIAL keys, VARCHAR lengths, indexes) is intentionally left to you.
How are nested objects and arrays handled?
They are serialized as JSON strings into TEXT columns. Postgres users can change those columns to JSONB and query inside them; alternatively, flatten the JSON before converting if you want proper relational columns.
Is one INSERT per row inefficient for large datasets?
For thousands of rows it is fine inside a transaction (wrap with BEGIN/COMMIT). For very large datasets, prefer your database's bulk path: SQLite .import, Postgres COPY, or MySQL LOAD DATA - convert to CSV instead for those.
Why did all my numeric-looking strings become TEXT?
Type inference uses the JSON types, not the appearance of values. "42" (a JSON string) stays TEXT deliberately - IDs with leading zeros and phone numbers corrupt when forced to numbers. Convert types in the JSON first if they really are numeric.
Last updated:
You might also need
Free and in-browser, like everything on JSON Console. Browse all tools →