Most of the JSON I deal with starts life as an API response and needs to end up in a database. On the toolz.dev backend, which runs on Express and TypeORM over PostgreSQL, I have lost count of the times I had a JSON export from one service that I wanted to load into a table for a quick query, a migration seed, or a local reproduction of a bug. Doing it by hand is grim: you write a CREATE TABLE, then you hand-type INSERT statements, quoting every string, doubling every apostrophe, remembering which fields are numbers, and turning missing keys into NULL. Get one row wrong out of two hundred and the whole batch fails to run.
A JSON to SQL converter does that mechanical work for you. You paste an array of objects, pick a database dialect, and it produces a CREATE TABLE with sensible column types plus the INSERT statements to load every row. This guide explains how the conversion works, the decisions it makes about types and quoting, and the real situations where it saves an afternoon.
TL;DR: The JSON to SQL Converter turns a JSON array of objects into
CREATE TABLEandINSERTstatements for MySQL, PostgreSQL, SQLite, or standard SQL. It reads object keys as columns, infers each column type from the data, escapes strings, turns missing keys and nulls intoNULL, and stores nested objects as JSON. Everything runs in your browser, so an API response with real data never leaves your machine. For the reverse or for tabular sources, see CSV to SQL and JSON to CSV.
What does a JSON to SQL converter do?
JSON and SQL model data in fundamentally different ways. JSON is a tree of nested objects and arrays with dynamic, per-value types. A relational table is a flat grid of fixed, typed columns. Converting from one to the other is a series of small decisions, and the value of the tool is making those decisions consistently.
It reads the keys of your objects as the column set, treats each object as a row, chooses a SQL type for every column, and then writes out the statements. The output has two parts: an optional CREATE TABLE that declares the columns with their inferred types, and the INSERT statements that carry the values. You can paste the result into a database client, save it as part of a migration, or pipe it into mysql, psql, or sqlite3 from the command line.
The input is normally an array of objects, like [{ "id": 1, "name": "Ada" }, { "id": 2, "name": "Grace" }]. A single object works too and becomes one row. What it will not accept is an array of bare values such as [1, 2, 3], because there are no keys to turn into columns, and it tells you so rather than guessing.
How are column types inferred?
This is the part that separates a useful converter from one that dumps everything into text columns. For each column, the tool scans the value in every row and picks the narrowest type that fits all of them.
If every present value in a column is a whole number, the column becomes an integer type. If the values are numbers but some have decimals, it becomes a floating-point type. If every value is true or false, it becomes a boolean. If every value is a nested object or array, it becomes a JSON type. Anything else, including a column where the values disagree, falls back to text so the INSERT cannot fail on a type mismatch.
null and missing keys are skipped when deciding the type; they only make the column nullable in practice. That means a column that holds numbers in most rows and null in a few is still typed as a number, which is what you want.
The concrete type name depends on the dialect. Here is how the neutral kinds map:
| Inferred kind | MySQL | PostgreSQL | SQLite | Standard SQL |
|---|---|---|---|---|
| Integer | INT |
INTEGER |
INTEGER |
INTEGER |
| Decimal | DOUBLE |
DOUBLE PRECISION |
REAL |
REAL |
| Boolean | TINYINT(1) |
BOOLEAN |
INTEGER |
BOOLEAN |
| Nested JSON | JSON |
JSONB |
TEXT |
TEXT |
| Text | VARCHAR(255) |
TEXT |
TEXT |
TEXT |
You can turn type inference off entirely, in which case every column becomes text. That is occasionally what you want when you are loading data into a staging table and plan to cast it later.
How does it handle the awkward parts of real data?
Real JSON is rarely uniform, and the conversion has to cope. The tool handles three cases that trip up naive converters.
First, objects with different keys. If one object has an email field and another does not, the column set is the union of every key that appears, kept in the order first seen, and any object missing a key gets NULL in that column. The tool warns you when the objects are not uniform so you are not surprised.
Second, nested objects and arrays. SQL columns are flat, so a value like { "street": "1 Main St", "city": "London" } cannot become several columns automatically without you deciding the shape. Instead the converter serializes the nested value back to JSON text and stores it in a JSON column on MySQL, a JSONB column on PostgreSQL, or a text column elsewhere. The structure stays intact and you can query it later with your database's JSON functions.
Third, mixed types in one column. If a field is a number in one record and a string in another, forcing a numeric type would make half the inserts fail. The tool detects the disagreement and types the column as text, then quotes every value as a string literal so the batch runs cleanly.
How are values escaped?
Correct escaping is the difference between a script that runs and one that throws a syntax error on row 47. The rules the converter applies are the standard SQL ones.
Text values are wrapped in single quotes, and any single quote inside a value is doubled, so O'Brien becomes 'O''Brien'. This is ANSI SQL string escaping and it works across all four dialects. Numbers and booleans are written without quotes, because a quoted number is a string in most engines. Booleans render as TRUE and FALSE on PostgreSQL and standard SQL, and as 1 and 0 on MySQL and SQLite, matching how each engine stores them. null and missing keys become the unquoted keyword NULL.
Identifiers, meaning the table and column names, are quoted too, with backticks on MySQL and double quotes everywhere else. That keeps a column named order or select from colliding with a reserved word.
How to use the JSON to SQL Converter
Step 1: Paste your JSON
Drop in an array of objects, or press Load Sample to see the expected shape. Each object becomes one row.
Step 2: Name the table and pick a dialect
Type the target table name and choose MySQL, PostgreSQL, SQLite, or standard SQL. The dialect controls the quoting style, the type names, and how booleans and nested JSON are written.
Step 3: Set the output options
Decide whether to include the CREATE TABLE, whether to infer column types, and whether to emit one multi-row INSERT or one statement per row. A single multi-row insert loads faster; one statement per row produces a diff-friendly file and lets you run rows individually.
Step 4: Copy the SQL
Read the generated statements and copy them. Paste the script into your database client or run it from the command line to build and load the table.
Common use cases
Seeding a database from an API response
You are building a feature and need realistic rows to work against. Pull a JSON response from the upstream API, paste it in, and you have a CREATE TABLE and inserts ready to seed your local database. No hand-typing, no missed quotes.
Turning a config or export into a table
A service exports its data as a JSON array. You want to run ad-hoc SQL queries against it rather than writing JavaScript to filter the array. Convert it to SQL, load it into SQLite, and query it with the language built for exactly that.
Building a migration seed
Framework migrations often need a seed step that inserts reference data. Generating the INSERT statements from a known-good JSON fixture gives you a stable, reviewable block to paste into the migration, rather than translating the data by hand.
Reproducing a production bug locally
A bug only appears for a specific set of records. Take the JSON for those records, convert it to inserts, load them into your local database, and reproduce the issue without copying a production database.
Multi-row vs per-row INSERT: which to choose?
A multi-row insert bundles every row into one statement with many VALUES tuples. It is compact and loads fastest, because the database parses and plans one statement instead of hundreds. Choose it for bulk loading.
One statement per row is more verbose but has two advantages. It produces a file where each row is its own line, which reads cleanly in a code review and diffs well in version control. And if one row violates a constraint, the others still succeed, which is handy when you are loading messy data and want to see which rows fail rather than losing the whole batch. Choose it for seeds you will commit or for data you do not fully trust yet.
Running the generated SQL from the command line
Once you have the script, loading it is a one-liner in each engine. For SQLite, save the output to a file and pipe it in: sqlite3 mydata.db < insert.sql creates the table and loads the rows into a fresh database file. For PostgreSQL, psql -d mydb -f insert.sql runs the whole script against the named database. For MySQL, mysql -u user -p mydb < insert.sql does the same. Because the generator quotes identifiers and escapes values for the dialect you picked, the script runs without the manual fixups that hand-written SQL usually needs.
If you generated one statement per row rather than a single multi-row insert, wrapping the load in a transaction is worth doing. Adding BEGIN; at the top and COMMIT; at the bottom turns hundreds of individual inserts into one atomic operation, which is both faster and safer: if a later row fails a constraint, the whole load rolls back instead of leaving the table half populated. For a multi-row insert this is already effectively atomic, since it is a single statement.
Performance and limits with large arrays
The conversion itself is linear in the size of the input and runs entirely in your browser, so a few thousand rows convert instantly. The practical limits are not in the tool but in what you do with the output. A single multi-row INSERT with tens of thousands of tuples can exceed a database's maximum statement size or packet limit, MySQL's max_allowed_packet being the one people hit first. If you are loading a very large array, either switch to one statement per row so each is small, or split the input into batches of a few hundred rows and convert them separately.
There is also a precision caveat worth knowing. JSON numbers are parsed by the browser's JSON engine into standard double-precision floats, so an integer larger than about nine quadrillion, beyond JavaScript's safe integer range, may lose precision before the tool ever sees it. That is a property of JSON parsing in every environment, not of the converter, but it means a giant numeric id is safer represented as a string in the source JSON, which the tool will then store as text and preserve exactly.
Where this fits with other tools
JSON to SQL is one direction of a small family. When your source is a spreadsheet or CSV export rather than JSON, CSV to SQL does the same job from tabular input with the same type inference and escaping. When you need the data as a flat file instead of a database, JSON to CSV flattens the array into rows, and CSV to JSON goes back the other way. Before you convert anything, JSON Formatter will pretty-print and validate the JSON so you catch a stray comma before it becomes a parse error. And once you have the SQL, SQL Formatter will indent and align the statements for a migration file you are proud to commit.
For the reasoning behind doing all of this in the browser rather than uploading data to a converter service, the data privacy in online tools guide lays out the client-side model, and the web developer toolkit collects the utilities that pair well with data conversion work.
FAQ
How do I convert JSON to SQL?
Paste a JSON array of objects, set the table name, and choose your SQL dialect. The tool reads the object keys as column names, infers each column type, and generates a CREATE TABLE plus INSERT statements you can copy and run in your database.
What JSON shape does it accept?
An array of objects is the normal input, where each object is one row. A single object also works and produces one row. Arrays of primitives or deeply mismatched shapes are rejected with an error explaining what is expected.
Which SQL databases are supported?
The converter outputs statements for MySQL, PostgreSQL, SQLite, and standard SQL. The dialect you pick controls identifier quoting, the type and boolean syntax, and the native JSON type, so the script runs in that database without edits.
How are column types decided?
Each column is checked against every object. If all present values are whole numbers it becomes an integer type, all numbers become a decimal type, all true or false values become a boolean type, all objects or arrays become a JSON type, and anything mixed becomes text.
What happens to nested objects and arrays?
They are serialized back to JSON text and stored in a JSON column on MySQL, a JSONB column on PostgreSQL, or a TEXT column on SQLite and standard SQL. This keeps the structure intact so you can query it with your database JSON functions later.
What if my objects have different keys?
That is fine. The columns are the union of every key that appears, kept in the order first seen. Any object missing one of those keys gets NULL in that column, and the tool warns you when the objects are not uniform.
How are strings and quotes escaped?
Text values are wrapped in single quotes and any single quote inside a value is doubled, which is the standard SQL escape. Numbers and booleans are left unquoted, null becomes NULL, and identifiers are quoted with backticks for MySQL or double quotes for the other dialects.
Is my JSON uploaded anywhere?
No. Parsing and SQL generation run as JavaScript in your browser. Nothing is transmitted, logged, or stored, and the tool keeps working offline once loaded, which you can confirm by watching the network tab while you convert.
