100% local — your data never leaves your browser

JSON to MySQL — A CREATE TABLE You Can Run

Turn a JSON sample into a MySQL CREATE TABLE. Column types come from the values, and a string too long for VARCHAR(255) gets TEXT instead.

Instant Private Zero cookies

JSON input

MySQL output

What this tool does

A JSON sample becomes a CREATE TABLE.

{ "id": 1, "firstName": "Ada", "score": 9.5, "address": { "city": "Paris" } }
CREATE TABLE `root` (
  `id` BIGINT NOT NULL,
  `first_name` VARCHAR(255) NOT NULL,
  `score` DOUBLE NOT NULL,
  `address` JSON NOT NULL
);

Column names are snake_case and backticked, so a reserved word or a dash in a key is not a problem. Two keys that collapse to the same name are suffixed rather than merged.

A column that fits the value

Strings become VARCHAR(255) — except when the sample shows they do not fit:

{ "bio": "…301 characters…" }
  `bio` TEXT NOT NULL

MySQL in strict mode — the default since 5.7 — rejects a value longer than the column with error 1406. A VARCHAR(255) here would have given you a table that cannot hold the document that generated it. That was a real defect, found while writing this page and fixed.

The cut-off is the sample’s own longest value, so it is a floor, not a promise: if production strings run longer than what you pasted, widen the column.

All the rows, not just the first

[{ "a": 1 }, { "a": 2, "b": "x" }]
CREATE TABLE `root_item` (
  `a` BIGINT NOT NULL,
  `b` VARCHAR(255) NULL
);

The table used to be built from the first object alone, so the second row of your own sample would fail to insert — Unknown column 'b'. The columns are now the union of every object, and a key missing from some of them is nullable, because it is.

The type follows the same rule. A key that holds 1 on one row and "x" on the next used to take whichever type came first, and the other value then had no column to go into; it gets a JSON column now, which holds both. A 300-character value that only shows up on the tenth row widens that column to TEXT just as it would have on the first.

What is not invented

  • No primary key, no index, no engine or charset clause. All of them are decisions about your data and your server; a document says nothing about them.
  • NOT NULL everywhere a value was present, NULL for a null and for a key that is missing from some rows.
  • Objects and arrays become JSON columns. No related table, no foreign key: a sample cannot show a relation, and inventing one would be three guesses stacked.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Why is one of my columns TEXT and the others VARCHAR(255)?
Because that value did not fit. `VARCHAR(255)` is the default here, and MySQL in strict mode refuses a longer value with error 1406 — the table would not hold the very sample it came from. Past 255 characters the column becomes `TEXT`. If your real data is longer than the sample, widen it yourself.
Where is the primary key?
Nowhere: a sample does not say which column identifies a row. An `id` that looks unique in one document may repeat in the next. Adding `PRIMARY KEY (id)` — or an `AUTO_INCREMENT` surrogate — is one line, and it is a decision about your data rather than a reading of it.
Why is my nested object a JSON column?
Because SQL has no nested types and a sample shows no relations. `{"address": {"city": "Paris"}}` could be a joined table or a blob that belongs in the row; inventing the table, the foreign key and the direction would be three guesses. MySQL 5.7 and later store it as `JSON`, which keeps the data queryable.

Related converters