JSON to SQL CREATE TABLE — Infer a Schema
Turn a JSON array of objects into a CREATE TABLE statement — column types inferred from your data, NOT NULL where every row has a value, and an id primary key detected automatically.
From a JSON sample to a table definition
Have an API response or an export and need somewhere to store it? This tool reads a JSON array of objects and writes the CREATE TABLE to hold it. Every key becomes a column, and its type is inferred from the actual values across all rows: whole numbers become INTEGER (or BIGINT when a value is too large for 32 bits), decimals become DOUBLE PRECISION, true/false become BOOLEAN, and text becomes VARCHAR sized to the longest value you gave (falling back to TEXT past 255 characters). Nested objects and arrays are stored as JSONB on PostgreSQL, JSON on MySQL.
Nullability & keys, inferred honestly
A column is marked NOT NULL only when every row supplies a non-null value — the moment one row omits the key or holds null, the column stays nullable. If a column called id is an integer that is always present and never null, it is emitted as the PRIMARY KEY. When the data does not justify a constraint, the tool leaves it off rather than guess wrong — you stay in control of what the schema promises.
Pair it with the data loader
This tool builds the table; JSON to SQL generates the INSERT statements to fill it — run the CREATE first, then the inserts. Need to shape the JSON before either step? Use JSON Flatten to collapse nested objects into columns, or the JSONPath filter to pick just the fields you want. The inferred types are a strong first draft — widen a column or add indexes and defaults to fit production before you ship it.
Frequently asked questions
How are column types inferred?
Every value in a column is scanned across all rows. All-integer columns become INTEGER (or BIGINT if a value exceeds the 32-bit range), decimals become DOUBLE PRECISION, true/false become BOOLEAN, and strings become VARCHAR sized to the longest value (or TEXT above 255). Nested objects and arrays become JSONB on PostgreSQL, JSON on MySQL, TEXT otherwise. A column mixing incompatible types widens to TEXT.
How is NOT NULL decided?
A column is marked NOT NULL only when the key is present in every row and never null. If any row omits the key or has a null value, the column is left nullable — the safe default.
Where does the PRIMARY KEY come from?
If a column is named exactly "id", is integer-typed, present in every row and never null, it is emitted as the PRIMARY KEY. No id column, or an id with nulls or non-integers, means no primary key is guessed — add one yourself.
What is the difference between the dialects?
Identifier quoting (MySQL backticks vs. double quotes) and the JSON/floating-point type names. PostgreSQL uses JSONB and DOUBLE PRECISION, MySQL uses JSON and DOUBLE, Standard falls back to TEXT for JSON. Pick the database you target, or Standard if unsure.
Is the DDL ready to run as-is?
Treat it as a strong first draft. The types are inferred from a sample, so a column that is always small in your sample but large in production may need widening, and constraints, indexes and defaults are yours to add. Everything is generated in your browser; nothing is uploaded.