JSON to SQL

Table name

Dialect

Include CREATE TABLEMulti-row INSERTs

JSON Input

SQL Output

SQL statements will appear here..

Why Use Our JSON to SQL Converter?

You have an API response or a test fixture and you want it in a table. The two usual routes both cost something. Typing the INSERT statements by hand is slow and gets slower with every column. Bouncing the JSON through CSV first is quicker but lossy: true becomes the text "true", null becomes the text "null", and a nested object becomes the string [object Object]. This page reads the JSON values directly, so a boolean stays a boolean, a missing key becomes NULL, and a nested object is stored as its JSON text.

The interesting part of converting JSON to SQL is not the syntax, it is the types. JSON has real booleans, real numbers and a real null; CSV has none of those, only text. That difference is why the JSON to CSV to SQL route quietly damages data, and why this page exists as its own tool rather than a link to the other two.

Each column is decided by the values actually present across every row. Integers stay integers; an integer column widens to a numeric one the moment a decimal appears; a boolean beside a number makes the column text, because no dialect stores both in one place. Nulls and missing keys are ignored while deciding, so they can never narrow a column to text.

The dialect choice changes two things and only two things. Identifier quoting: double quotes for PostgreSQL and SQLite, backticks for MySQL, with any quote character inside a name doubled so a hostile column name cannot break out. And the type names written into the CREATE TABLE — plus the booleans, since SQLite has no boolean literal and stores 1 and 0 instead.

Nested objects and arrays are written as JSON text rather than expanded into extra tables. That is a deliberate limit. Deciding that an array of objects should become a second table with a foreign key is schema design, and a converter that guessed at it would be wrong often enough to be worse than useless.

How it compares

Most online JSON to SQL tools post your JSON to a server. An API payload usually carries exactly the fields you would not want on somebody else's disk — email addresses, tokens, customer names. This page generates the SQL in your browser, so the JSON never leaves the tab.

The other common workaround is a two-step trip through JSON to CSV and then CSV to SQL. It works for a flat array of strings and numbers, and it is the wrong tool the moment a value is a boolean, a null or a nested object, because CSV cannot carry any of those as anything but text.

Going the other direction, SQL to CSV reads rows back out of a dump, and SQL Formatter pretty-prints the statements once you have them.

JSON to SQL Tips

Keys are unioned across every row in first-seen order, so a row with an extra field widens the table instead of being clipped.
A key missing from one row and a key explicitly set to null both become NULL — there is no way to tell them apart in SQL.
A null never decides a column's type. A column of nulls and integers is an integer column.
Nested objects and arrays are stored as JSON text in one column. Splitting them into related tables is a schema decision, not a conversion.
Turn on multi-row INSERTs for a large array. Statements are chunked at 500 rows so no single statement becomes unmanageable.

Frequently Asked Questions

Does my JSON get uploaded anywhere?

No. The JSON is parsed in your browser and the SQL is generated there. Nothing is sent to a server.

How are column types decided?

From the real JSON values, across every row. A whole-number column is an integer, a decimal widens it to numeric, true and false give a boolean, and anything else is text. A null or a missing key is ignored while deciding, so it can never narrow a column.

What happens to a nested object or an array?

It is stored as its JSON text in one column — never the string [object Object], which is what you get from routing the data through CSV. Splitting nested data into related tables is schema design, so the tool leaves that to you.

How is null handled?

A null value and a key missing from that row both become NULL. SQL has no way to distinguish the two, so neither does the output.

Which SQL dialects are supported?

PostgreSQL, MySQL and SQLite. The dialect changes identifier quoting, the type names in the CREATE TABLE, and how booleans are written — SQLite has no boolean literal, so it gets 1 and 0.

What if my rows have different keys?

The columns are the union of every key, in the order they are first seen. A row that lacks one of them gets NULL for that column, so nothing is clipped.

Can I paste a single object instead of an array?

Yes. A single object is treated as a one-row array. NDJSON — one JSON object per line — is also accepted, and is tried automatically if the whole paste is not valid JSON on its own.

What is the difference between one INSERT per row and multi-row INSERTs?

One statement per row is easier to read and easier to run partially. Multi-row INSERTs are considerably faster to execute on a large array. They are chunked at 500 rows so no single statement becomes unmanageable.

Does it create indexes, keys or constraints?

No. The CREATE TABLE names the columns and their types and nothing else. Primary keys, foreign keys and indexes depend on how you intend to query the data, which the JSON does not say.

Can I use this from a script or an AI client?

Yes. The same generator is available over HTTP and to MCP clients, so an agent can produce the SQL without opening this page. The reference pages for both surfaces are linked from the tool.

Run it from code

$ curl -X POST \
  api.findutils.com/api/tools/json-to-sql/execute \
  -d '{"json":"[{\"id\":1,\"name\":\"Ada\",\"active\":true}]","table":"people","dialect":"postgres"}'

$ claude mcp add findutils \
  --transport http https://mcp.findutils.com/
# then call findutils:json_to_sql

API reference Add to Claude