creatorvalet
FilesConvert, compress and reshape files — without uploading them anywhere.MetadataSee what your files quietly carry, then strip exactly what you choose.Text & dataFormatters, converters, and the character-encoding fixes nobody else gets right.PublishingCheck how your pages read to crawlers, to people, and to language models.CodesBarcodes, QR and identifiers that keep working after you publish them.CharactersFind the character you can draw but cannot name — and the font you cannot place.

Convert SQL to JSON

Reads INSERT statements properly — quoting, escapes and all — and hands back the rows as JSON you can paste into a test.

Runs in your browser0 bytes uploaded
Waiting
Tables
—
Rows
—
Columns
—
№ 5637waiting

Paste SQL or drop a .sql file. The tables in it are listed first, with their row counts — nothing is uploaded to read them.

Who converts SQL to JSON, and why it changes the output

The people who want a spreadsheet and the people who want JSON are after different things, and pretending otherwise produces a tool that serves neither well. A JSON export is almost always going somewhere a program will read it: a test fixture, a seed file, a mock response for a frontend that is being built before the API is, a sample somebody needs in a bug report.

That has consequences on this page. There are two output shapes rather than one, values are written as strings on purpose, and expressions in the dump are left as written rather than evaluated. Each of those would be the wrong call for a spreadsheet and is the right one here.

Objects or arrays, and when the choice starts to matter

One object per row is what a fixture looks like. It reads without explanation, it drops straight into a test, and anybody opening the file understands it immediately. It is the default for that reason.

The other shape — a header row followed by an array per record — exists for size. In the object form every key is repeated on every row, so a table with columns calledcustomer_shipping_address_line_1 spends more bytes on names than on data. At ten thousand rows that is the difference between a file your editor opens instantly and one it thinks about. Same information, and one of them is several times smaller.

Why every value is a string

This looks like laziness and is the opposite. JSON numbers are IEEE doubles, which means an integer beyond about fifteen digits cannot be represented exactly — and every language parsing the file will round it without telling anyone. Modern IDs are routinely nineteen digits. Convert one to a JSON number and you get a different ID back, one that still looks entirely plausible.

The leading-zero problem is the same story with a shorter number: 007becomes 7, and a postcode written 01234 stops being a postcode. Keeping everything as a string preserves exactly what the dump contained. Casting three columns yourself afterwards takes a line of code; recovering a rounded identifier takes access to the original database, which is usually the thing you did not have.

What the reader refuses to invent

A value written NOW() comes out as the text "NOW()".1+1 comes out as "1+1". Evaluating them would require a SQL engine and a decision about whose SQL engine, and the answer would be wrong in a way that is impossible to notice: NOW() in a dump means whenever the statement runs, not the moment you happened to convert the file.

The same restraint applies to column names. When an INSERT carries no column list and there is no CREATE TABLE above it, the values exist but the names genuinely do not — so the columns are numbered by position and the page says that is what happened. Inventing plausible names would be more comfortable and would be a lie about which field is which.

Reading the dump correctly is most of the work

Everything above assumes the rows came out right, and that is the part that is hard. A naive reader matching VALUES with a pattern is defeated by a semicolon inside a value, by a bracket inside a value, by a comma inside a value, and by the fact that MySQL escapes apostrophes with a backslash while PostgreSQL does not. All four failures are silent — they produce rows, just not your rows.

Here the file is tokenized first, so strings, comments and quoting are already resolved before anything is extracted, and the dialect that was assumed is stated on screen with the evidence behind it. You can override it if the guess is wrong.

The file never leaves this tab

Tokenizing and serializing both happen in your browser, with no upload endpoint to send anything to. A dump is the strongest case this site's promise ever has to make: it is not a document but every row of every table you have, and there is no version of "convert this for me" that justifies handing over the lot. Large files are read off the main thread rather than refused.

Questions

Which shape should I choose?

Objects if a person is going to read it, arrays if the file is going to be large. One object per row is what a fixture or a seed file looks like and it needs no explanation when somebody opens it. A header row followed by arrays repeats each key once instead of once per row, which on ten thousand rows with long column names is the difference between a file you can open and one you cannot.

Why are numbers written as strings?

Because turning them into JSON numbers loses data in exactly the ways this site exists to avoid. A leading zero disappears. An identifier longer than fifteen digits gets rounded, silently, because JSON numbers are IEEE doubles and JavaScript will not hold that integer exactly. Strings preserve what the dump actually contained, and casting three columns yourself is easy — recovering a rounded ID is not.

What happens to NULL?

It becomes an empty string, which is a compromise worth being explicit about. Writing JSON null would be more faithful for a column that is genuinely nullable, but the same output has to work for every column, and an empty cell in a CSV export and a NULL in the database arrive here as the same thing. If the distinction matters to you, keep the column and check it against the original.

Does it evaluate expressions in the values?

No. A value written as NOW() or 1+1 comes out as the text "NOW()" or "1+1". Computing them would need a SQL engine and a decision about which one, and guessing would be worse than leaving them alone — a dump that says NOW() means whenever it runs, not whenever you converted it.

Is anything sent to a server?

No. The tokenizer and the serializer run in this tab, so the dump never leaves your machine. It is the strongest version of this site's promise, because a database dump is not one document — it is every row of every table you have.