SQL Formatter

SQL formatting rewrites a query's whitespace so its structure becomes visible. Each major clause — SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY — starts on its own line, the expressions beneath it are indented, and boolean conditions line up underneath the clause they belong to. The query itself is unchanged; only the layout differs.

This matters most for queries you did not write: an ORM-generated statement pulled from a slow-query log, a one-line query copied out of application code, or a report someone emailed you. Reading a 400-character single line to find the join condition is slow and error-prone. Formatted, the same query can be scanned in seconds.

Keyword casing is the other half of readability. Most teams standardise on uppercase keywords with lowercase identifiers so the language and your schema are visually distinct. This tool lets you apply either convention, or leave casing exactly as you typed it.

It is fully client-side. Queries often contain table names, column names and literal values that reveal a lot about a production system, so the safest formatter is one that never transmits the query at all. Nothing you paste here leaves your browser.

It is dialect-agnostic by design. Rather than parsing to a specific dialect's grammar, it works on a token level, so Postgres, MySQL, SQLite, SQL Server and BigQuery queries all format sensibly — including comments and string literals, which are left untouched (see the quoting note below for one SQL Server-specific exception).

And it stays out of your way: no account, no query size cap, no ads crowding the editor.

Comments and string literals stay untouched

Comments and string literals are left exactly as written — a token-level formatter that reflowed the contents of a string literal (say, one containing the word SELECT) would silently corrupt the query, so both are treated as opaque and passed through untouched no matter what whitespace or keywords they contain internally.

CTEs, UNIONs and window functions

Multi-line constructs get sensible defaults without needing to be told about them specifically. A query with a CTE indents the parenthesized SELECT inside WITH name AS (...) one level deeper than the line that opens it, and a multi-branch UNION or UNION ALL puts each branch on its own line at the same indent so the columns line up for comparison. Window functions and their OVER (...) clauses aren't given special line-breaking yet — they format on one line, which stays readable for a short PARTITION BY but is worth reviewing by eye once the clause gets long.

Dialect-specific quoting (including SQL Server brackets)

Because formatting works at the token level instead of parsing a specific dialect's full grammar, single-, double- and backtick-quoted strings and identifiers — covering Postgres and MySQL quoting — are treated as opaque and preserved exactly as written, so the same formatter works sensibly across dialects without picking one upfront. SQL Server's [bracketed] identifiers aren't recognized as quoted text the same way, so double-check a bracket-heavy SQL Server query's output before relying on it.