Format Bench › SQL Formatter
SQL Formatter and Beautifier
Paste a query and press Format. Major clauses start new lines, nesting is indented, and keyword case is normalised, which makes a long query readable without changing what it does.
● Runs locally. What you paste never leaves this page.
What formatting does and does not change
Formatting rewrites layout only. Identifiers, string literals, comments and the order of clauses are untouched, so the formatted query is the same query. The one thing that changes beyond whitespace is keyword case, and only when you ask for it: reserved words such as SELECT and JOIN can be upper-cased, lower-cased or left alone. Table and column names are never re-cased, because in some databases identifier case is significant.
The layout rules applied
- Major clauses (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT and the statement forms for INSERT, UPDATE and DELETE) each begin a new line at the current nesting level.
- Every join form begins a new line, including the multi-word variants such as LEFT OUTER JOIN, which are recognised as single units.
- Select list items break after each comma, so a wide projection reads as a column per line instead of running off the screen.
- AND and OR in a predicate start new lines and are indented under their clause, which is what makes a compound WHERE readable.
- Parentheses increase indentation, so subqueries and CTE bodies sit visibly inside their parent.
- Comments, both the double-dash and slash-star forms, are preserved on their own lines.
- String literals are tokenised properly, including doubled quote escapes, so a keyword appearing inside a quoted string is never mistaken for SQL.
Dialects
The formatter is deliberately dialect-agnostic. It works on the shared grammar that PostgreSQL, MySQL, SQL Server, SQLite, Oracle, Snowflake and BigQuery have in common, which covers the overwhelming majority of everyday queries. Backtick, double-quote and single-quote delimiters are all handled, so MySQL and PostgreSQL identifier styles both survive intact.
Because it does not parse to a full syntax tree, it will not reject invalid SQL. It is a formatter, not a linter. A query with a genuine syntax error will be laid out, not diagnosed. Vendor-specific extensions with unusual syntax are passed through rather than specially aligned.
Why this matters beyond aesthetics
Consistent formatting makes review diffs meaningful. When queries live in version control, an inconsistently formatted query produces diff noise every time anyone touches it, which hides the one predicate that actually changed. Normalising layout before committing collapses that noise, the same way sorting keys does for JSON.
Questions
Does formatting change what my query returns?
No. Only whitespace and, optionally, the case of reserved keywords are altered. Identifiers, literals, comments and clause order are preserved exactly, so the query is semantically identical.
Which SQL dialect does it target?
None specifically. It formats the grammar common to PostgreSQL, MySQL, SQL Server, SQLite, Oracle and the cloud warehouses, and handles backtick, double-quote and single-quote delimiters, which covers ordinary queries in all of them.
Will it tell me if my SQL is invalid?
No. This is a formatter rather than a parser or linter, so a query with a syntax error will still be laid out. Use your database client to check validity.
Are table and column names re-cased?
Never. Only recognised reserved keywords are case-normalised, because identifier case is significant in some databases and changing it could break the query.