Does formatting change what my query does?

No. Only whitespace and keyword capitalisation change, and SQL keywords are case-insensitive. String literals, identifiers and comments are untouched, so the query means exactly what it did before.

Which dialect should I choose?

The one your database actually runs. It affects identifier quoting — SQL Server uses [brackets], MySQL uses backticks — and which words are treated as keywords. Standard SQL is a reasonable fallback if you are unsure.

Why is my query left mostly as it was?

Usually a syntax error earlier in the statement, which stops the tokeniser from recognising the structure. Check for an unbalanced parenthesis or an unterminated quote just before the point where formatting stops looking right.

Can it minify a query instead?

Not currently — this only expands. Minifying SQL saves very little, since the network cost of a query is dominated by its data rather than its whitespace, and the readability loss is real.

SQL Formatter

SQL → SQL

Make an unreadable query readable, in the dialect you actually use.

query

formatted

Formatted query appears here

The query is tokenised rather than pattern-matched, so string literals, quoted identifiers and comments are left exactly as written — a regex-based formatter will happily change the capitalisation inside your WHERE clause’s text.

About SQL Formatter

Paste a query that arrived as one long line — out of a log, an ORM, or a colleague's message — and get it back indented and readable. Fourteen dialects are offered, from standard SQL through PostgreSQL, MySQL, SQL Server and Oracle to BigQuery, Snowflake and ClickHouse, because each has keywords and quoting rules the others do not.

The formatting is done by tokenising the query, not by matching patterns, and that is the distinction that matters. A regex-based formatter cannot tell the difference between the keyword `from` and the word "from" inside a string literal, so it will change the capitalisation of your data or break an identifier that happens to contain a keyword. Here, literals, quoted identifiers and comments come through exactly as written.

Choosing the right dialect is worth a moment: it decides how `[bracketed]` or `` `backtick` `` identifiers are read, and which words count as keywords. If output looks subtly wrong, the dialect is usually why.

Common questions

Does formatting change what my query does?: No. Only whitespace and keyword capitalisation change, and SQL keywords are case-insensitive. String literals, identifiers and comments are untouched, so the query means exactly what it did before.
Which dialect should I choose?: The one your database actually runs. It affects identifier quoting — SQL Server uses [brackets], MySQL uses backticks — and which words are treated as keywords. Standard SQL is a reasonable fallback if you are unsure.
Why is my query left mostly as it was?: Usually a syntax error earlier in the statement, which stops the tokeniser from recognising the structure. Check for an unbalanced parenthesis or an unterminated quote just before the point where formatting stops looking right.
Can it minify a query instead?: Not currently — this only expands. Minifying SQL saves very little, since the network cost of a query is dominated by its data rather than its whitespace, and the readability loss is real.

This page does the work itself, in this tab. Nothing you paste is sent to a server. Close the tab and no copy remains.