SQL Formatter
Format SQL for Postgres, MySQL, SQLite, T-SQL and BigQuery, with keyword casing and indent width.
Runs entirely in your browser — nothing you paste is uploaded.
About SQL Formatter
The query that comes out of an ORM's debug log is one line, four hundred characters wide, and unreadable. This puts it back into shape: clauses on their own lines, joins aligned, subqueries indented, keywords cased consistently.
Formatting is dialect-aware because SQL isn't one language. PostgreSQL's `::` casts, MySQL's backtick quoting, T-SQL's square brackets and BigQuery's backtick-qualified table paths all parse differently, and a formatter that assumes the wrong dialect will mangle them. Pick the dialect and the parser follows its rules.
Output is idempotent — formatting an already-formatted query returns it unchanged. That sounds obvious and many formatters get it wrong; it matters when the formatter runs in a pre-commit hook or a CI check, because a non-idempotent one produces an infinite loop of diffs.
Nothing is sent anywhere. Queries carry table names, column names and often literal values from production, and pasting them into a hosted formatter is a data-exfiltration path that shows up in security reviews. This one runs in the tab.
Frequently asked
›Which dialects are supported?
PostgreSQL, MySQL, SQLite, T-SQL (SQL Server) and BigQuery, with a generic standard-SQL mode as the fallback. The dialect affects identifier quoting, cast syntax, and which words are treated as reserved keywords.
›Does it validate my SQL?
No. It's a formatter, not a parser with a schema — it will happily format a query that references a table that doesn't exist, or one with a logic error. Syntax broken enough to defeat the tokeniser will produce odd output rather than a clear error.
›Will it change what my query does?
No. Formatting only moves whitespace and changes keyword case. String literals, identifiers and comments are preserved exactly, including their contents — a formatter that reflowed the inside of a string literal would be a bug.
›Uppercase or lowercase keywords?
Uppercase keywords with lowercase identifiers is the dominant convention and makes the query's structure scannable at a glance. It's a style choice, not a correctness one — SQL keywords are case-insensitive. Pick one and apply it consistently.
›Can I use this on a query with parameters?
Yes. Placeholders in every common style — `?`, `$1`, `:name`, `@name` — are treated as tokens and passed through untouched.