SQL Formatter
Turn an unreadable SQL one-liner into something you can actually review — one clause per line, indented subqueries — or collapse it back down.
Only whitespace and comments are ever changed. No SQL token is renamed, reordered or removed, so the output cannot behave differently from your input. That also means the size reduction is smaller than tools which rewrite your code — no variable mangling, no dead-code removal — no merged selectors, no collapsed shorthands — and because SQL needs whitespace between tokens, it can only be collapsed, never removed. This formats your source; it does not compile it. Your types are preserved, not stripped.
/*! banner comment is always kept, the usual
convention for a licence header.
Drop a SQL file here
Up to 4 MB · nothing uploaded
{{ error }}
{{ commentWarning }}
Verified — every token preserved
The output was re-tokenized and compared against the input: all {{ tokenCount }} code tokens are identical, in the same order. Only whitespace and comments differ.
Output rejected
The result did not survive the token check, so it was discarded rather than shown to you. This is a bug in the tool, not in your code — please treat the input as unformatted.
Your SQL is tokenized and reformatted entirely in your browser. Nothing you paste or drop is ever uploaded to a server.
Turning a one-liner into something reviewable
Beautifying puts each major clause — SELECT, FROM, WHERE,
each JOIN, GROUP BY, ORDER BY — on its own line and
indents subqueries by nesting depth. Every keyword, identifier, literal and operator is left
exactly as you wrote it; only whitespace and comments move. The query you get back is the query
you pasted in.
Why minifying SQL barely shrinks it
Because SQL needs whitespace between tokens. SELECT and a column name
cannot be run together the way two CSS properties can, so whitespace here can only be collapsed
to single spaces, never removed. Minifying SQL is really about getting a query onto one line for
a log line or a config file — treat any byte saving as incidental.
The escape that trips up most hand-written SQL tools
A doubled quote inside a string literal is an escaped quote, not the end of the string:
'O''Brien' is one value, not two. A tokenizer that misses this ends the string
early and then reads the rest of your query as garbage. The same applies to
'-- not a comment' and '/* also not one */', both of which are strings
and are treated as such here, along with Postgres $$dollar-quoted$$ blocks.
Generic SQL, deliberately
T-SQL, PL/pgSQL and MySQL differ enough that a dialect-accurate parser is a separate project,
so this handles the common ANSI-style shape plus all three quoted-identifier styles
("col", `col`, [col]). It reports genuinely malformed
input with a line and column, but it does not validate your SQL — it will happily format a
query your database would reject.
Formatting JSON from a query result?
Use the JSON Formatter, which validates as well as formats.
Frequently asked questions
What does formatting actually change?
Only whitespace and comments. Every keyword, identifier, literal and operator is left exactly as written — the query you get back is the query you pasted in, laid out differently. Beautifying puts each major clause on its own line and indents subqueries; minifying collapses it to one line.
Why is the minified saving so small?
Because SQL needs whitespace between tokens. SELECT and a column name cannot be run together the way CSS properties can, so whitespace can only be collapsed to single spaces, never removed. Minifying SQL is really about getting it onto one line for a log or a config file, not about saving bytes.
Which SQL dialect does it support?
Generic, ANSI-style SQL. It deliberately does not try to parse dialect-specific grammar, because T-SQL, PL/pgSQL and MySQL differ enough that doing so accurately is a separate project. What it does handle is the part every dialect shares and that naive formatters get wrong: doubled-quote escapes, all three quoted-identifier styles, and dollar-quoted blocks.
Will it mangle a string containing -- or /*?
No. String literals are recognised before comments, so '-- not a comment' stays a string. A doubled quote inside a literal, as in 'O''Brien', is correctly read as an escaped quote rather than the end of the string — that single case is where most hand-written SQL tokenizers fail.
Does it validate my SQL?
No. It reports genuinely malformed input, such as an unterminated string or comment, with a line and column. It does not check that your tables exist, your syntax is valid for your database, or your query does what you intend.
Is my query uploaded anywhere?
No. Everything runs in your browser, which matters because queries frequently contain real customer data in their WHERE clauses.