SQL INSERT to JSON Converter

What is in scope: INSERT statements, not queries

This tool reads SQL INSERT statements and turns their VALUES tuples into JSON objects. That is the whole scope, and it is worth being precise about because "SQL to JSON" is an ambiguous phrase.

How to convert INSERT statements

1. Paste one or more statements Line comments (--, #) and block comments (/* … */) are stripped, so a statement copied straight from a dump file or migration works as-is.
2. Choose the output shape A flat array of every row, or an object keyed by table name when the input touches more than one table.
3. Check the row preview The first ten rows are shown as a table so you can confirm the columns lined up before trusting the JSON.
4. Copy or download The download filename is taken from the table name in the statement.

Why a character-level parser rather than a regular expression

The obvious approach to this problem is a regex that finds bracketed groups and splits them on commas. It fails on real data almost immediately, and the failures are silent — you get JSON out, but it is wrong.

Three cases break it:

-- A comma inside a string value
INSERT INTO people (name) VALUES ('Smith, John');
-- Naive split on "," produces two columns from one value.

-- A closing bracket inside a string value
INSERT INTO companies (name) VALUES ('Acme (UK) Ltd');
-- Matching /\(([^)]+)\)/ stops at the bracket inside the string.

-- A doubled quote, the SQL way of escaping an apostrophe
INSERT INTO people (name) VALUES ('O''Brien');
-- Treating the second quote as a terminator truncates the value to "O".

The parser here walks the statement one character at a time, tracking whether it is inside a quoted string and how deep it is in nested brackets. A comma only separates values at bracket depth zero and outside a string. That is the same approach a real SQL lexer takes, and it is the reason those three cases come out correctly.

Both '' (the SQL standard) and \' (the MySQL extension) are recognised as escaped quotes.

Examples: how SQL values map to JSON types

Input:

INSERT INTO orders (id, total, discount, note, created_at, paid) VALUES
  (1001, 129.99, NULL, 'Gift wrap', NOW(), TRUE);

Output:

[
  {
    "id": 1001,
    "total": 129.99,
    "discount": null,
    "note": "Gift wrap",
    "created_at": "NOW()",
    "paid": true
  }
]

That last row matters for real database exports. JavaScript numbers lose precision above 2⁵³−1, so a 64-bit ID such as a Snowflake identifier would silently change value if converted to a number. It is kept as a string instead, and a warning says so.

Decimals and money

By default 129.99 becomes the number 129.99. That is convenient but it is a binary float, so 0.1 + 0.2 style rounding applies downstream. When the values are currency and will be summed, switch on "Keep decimals as strings" so the exact digits survive.

Column names and identifier quoting

Identifiers are unquoted before being used as JSON keys, across all three conventions:

MySQL:      `user_id`     →  user_id
PostgreSQL: "user_id"     →  user_id
SQL Server: [user_id]     →  user_id

Schema-qualified table names are preserved, so public.users stays public.users in the grouped output.

An INSERT with no column list is a special case:

INSERT INTO users VALUES (1, 'Ada', TRUE);

The column names are not in the statement — they live in the table definition. Keys are generated as column_1, column_2, column_3, and a warning explains why. Rename them, or paste a version of the statement that names its columns.

When a column list is present, the value count is checked against it row by row. A mismatch is reported with the row number and both counts, because a single missing comma in a long tuple otherwise shifts every value silently.

Use cases

• Building test fixtures from real seed data. A migration's INSERT block becomes a JSON fixture for unit tests without retyping it.
• Mocking an API from a database dump. Turn a table's rows into a JSON array that a mock server or MSW handler can return.
• Moving relational rows into a document store. A first pass at the shape before adding nesting by hand.
• Reviewing a migration you did not write. A table preview of the parsed rows is far easier to check than a wall of tuples.
• Populating a spreadsheet. Convert to JSON here, then to columns with JSON to CSV.
• Finding a bad row in a failing import. The value-count check names the row and the mismatch, which is usually the actual bug.

Going the other direction, or working with different formats: CSV to JSON handles spreadsheet exports, SQL Formatter tidies the statement itself, and JSON to YAML takes the result further.

Privacy

Parsing runs entirely in your browser. The SQL is not uploaded, not stored, and not written to browser storage — it exists only in the page while the tab is open.