SQL to JSON

Runs in your browser · no SQL is executed

SQL input

Options

Group by table

Indent

Coerce numbersPer column: a column with a zero-padded ID like '007' stays all strings

Per column: a column with a zero-padded ID like '007' stays all strings

JSON output

nothing to convert yet

JSON appears here

Each table becomes an array of row objects, keyed by column name.

{ "users": [
    { "id": "007", "name": "Ada" }
] }

Why Use Our SQL to JSON Converter?

A .sql dump is the format databases export, and JSON is the format almost everything else reads: API fixtures, mock servers, test data, a quick script. Getting from one to the other normally means restoring the dump into a database, running a query and exporting the result. This page reads the INSERT statements as text instead and hands you JSON with the types intact: NULL is null, TRUE and FALSE are booleans, numbers are numbers. Nothing is uploaded and no SQL is executed, so a dump you are not allowed to send anywhere is still one you can convert here.

A SQL dump is a text file of statements. The rows are already sitting in it as literal values, so turning them into JSON needs a parser rather than a database engine. This page walks the file character by character, tracking strings, quoted identifiers and comments, so a -- or a semicolon inside a value is data rather than the end of a statement.

Types are carried across rather than guessed. NULL becomes null and an unquoted TRUE or FALSE becomes a boolean. An unquoted number becomes a JSON number unless a double cannot hold it exactly — beyond ±9007199254740991 or more than 15 significant digits — in which case it is kept as a string, so a 64-bit ID is not silently rounded. Quoted values stay strings; with Coerce numbers on, a quoted value becomes a number only when it writes back as the same text, so a zero-padded code such as '007' or a price such as '1.50' keeps its exact form.

What the page will not do is evaluate anything. NOW(), DEFAULT and CURRENT_TIMESTAMP are kept as their SQL text and flagged under the panel. Hex and bit literals stay as text. An INSERT … SELECT has no literal rows in the file, so it is listed by line number rather than guessed at.

If you want a spreadsheet instead, SQL to CSV reads the same statements with the same parser. Going the other way, JSON to SQL turns JSON back into INSERT statements.

How it compares

The usual route from a dump to JSON is to restore it: create a database, import the file, then run a query that builds JSON — SELECT … FOR JSON in SQL Server, json_agg in PostgreSQL, JSON_ARRAYAGG in MySQL. That gives you the database's own type rules and works for dumps of any size, but it needs the matching database installed and a restore that can fail on dialect differences. Reading the statements as text needs neither, at the cost of never evaluating functions or queries.

You could also chain two tools: SQL to CSV and then CSV to JSON. That works, but CSV has no types, so every value comes back a string, NULL turns into an empty cell, and the second step has to guess numbers back. Going straight from SQL keeps null, booleans and numbers as the dump wrote them. If you do need a CSV from the JSON later, JSON to CSV does that.

Many online converters upload the dump to a server. A database export is often the most sensitive file you handle, so this page parses it in your browser and never sends it anywhere.

SQL to JSON Tips

Column names come from the INSERT column list first, then from a CREATE TABLE earlier in the same input, then from positions (column_1, column_2 …). Paste the CREATE TABLE above the INSERTs if the dump omits column lists.
Coerce numbers decides per column. A quoted column becomes numbers only when every quoted value in it writes back as the same text, so '5' and '12' become 5 and 12, while a code column holding '007' stays all strings.
MySQL stores booleans as TINYINT(1), so a dump writes 1 and 0. Those stay the numbers 1 and 0; only an unquoted TRUE or FALSE becomes a JSON boolean.
Turn Group by table off to get one flat array across all tables, and add the __table field so each row still says where it came from.
Click a line chip under a skipped statement or an error to jump to that line in the SQL.

Frequently Asked Questions

How do I convert a SQL dump to JSON?

Paste the INSERT statements into the SQL panel or drop the .sql file onto it. The JSON appears on the right as you type. Copy it, or download it as a .json file.

What do I get when the dump has several tables?

With Group by table on, an object keyed by table name, each holding an array of row objects. A dump with rows for only one table gives a plain array. Pick a table from the chips to get just that table, turn grouping off for one flat array across all tables, or download a ZIP with one .json file per table.

Where do the column names come from when the INSERT has no column list?

From a CREATE TABLE for the same table earlier in the input. If there is none, the columns are named column_1, column_2 and so on by position. So include the CREATE TABLE statements when the dump has them.

How are NULL, booleans and numbers converted?

NULL becomes null and an unquoted TRUE or FALSE becomes a boolean. An unquoted number becomes a JSON number, written the way JSON writes it (42.50 becomes 42.5). Quoted values stay strings unless Coerce numbers is on. Then the choice is made per column: a quoted column becomes numbers only when every quoted value in it writes back as the same text. A quantity column of '5' and '12' becomes 5 and 12, while a code column holding '007' and '120' stays all strings, so no column mixes types. MySQL booleans stored as TINYINT(1) arrive as 1 and 0 and stay numbers.

What happens to very large integers such as 64-bit IDs?

A JSON number is a double, which holds integers exactly only up to ±9007199254740991 and about 15 significant digits. An unquoted number beyond that is kept as a string with its exact digits, and a note under the panel says so, rather than being rounded without warning.

Are INSERT … SELECT statements and functions like NOW() evaluated?

No. Nothing is executed. An INSERT … SELECT has no literal rows in the file, so it is listed under the SQL panel by line number and skipped. A function or keyword such as NOW(), DEFAULT or CURRENT_TIMESTAMP is kept as its SQL text in a string, and a note names the first one found.

Does it read pg_dump COPY blocks?

No. Only INSERT statements with literal VALUES are read. pg_dump writes COPY … FROM stdin blocks by default; those are not converted, and an apostrophe inside one can stop the parse with an unbalanced-quote error. Export with pg_dump --inserts or --column-inserts to get INSERT statements this page can read.

Is there a row limit?

The page stops at 50,000 rows per table and tells you when it did, so a very large dump cannot lock up the tab. Dumps over about 2 MB are converted in a background thread so typing stays responsive. Split the file if a table has more rows than the limit.

Is my SQL uploaded or executed?

Runs in your browser; nothing is uploaded and no SQL is executed. Analytics and ads may load on the page.

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

Yes. The same parser is available as a REST endpoint and as an MCP tool, with the same options: grouping, number coercion, a __table field, indent, a single table and a row limit. See the REST reference and the MCP reference.

Run it from code

$ curl -X POST \
  api.findutils.com/api/tools/sql-to-json/execute \
  -d '{"sql":"INSERT INTO people (id, name, active) VALUES (1, '\''Ada'\'', TRUE), (2, NULL, FALSE);"}'

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

API reference Add to Claude