SQL Formatter

Format SQL for eleven dialects with proper keyword casing, indentation and clause breaks.

Code FormattersRuns in your browserFree, no sign-up

Options

SQL dialect

Affects keyword lists and quoting rules.

Indentation

Keyword case

SQL query

Formatted SQL

Output appears here as you type.

Ctrl + Enter to run

About the SQL Formatter

Formatting a query is what makes its logic visible: which conditions belong to which branch of a `WHERE`, where a subquery begins and ends, and whether that `OR` is grouped the way you assumed. Most SQL bugs that survive review are precedence mistakes hiding in an unbroken line.

Dialect selection is not cosmetic. Quoted identifiers, string escaping and a great deal of syntax differ between PostgreSQL, MySQL, SQL Server and SQLite, and a formatter assuming the wrong one will either reject valid input or quietly restructure it. Pick the dialect you actually run.

Frequently asked questions

Why does the dialect matter?

Each dialect has its own keyword list, quoting rules and function names. Formatting a T-SQL query with standard-SQL rules can leave bracket-quoted identifiers like [Order] mis-indented, and PostgreSQL constructs such as DISTINCT ON or :: casts are only recognised by the right parser.

Should SQL keywords be uppercase?

It is a convention, not a requirement — SQL keywords are case-insensitive. Uppercase keywords with lowercase identifiers is the most widely used style because it makes the query structure scannable at a glance. Some modern teams prefer all-lowercase; both options are available.

Will formatting change what my query does?

No. Only whitespace and keyword casing change, and neither is semantically meaningful in SQL. String literals and quoted identifiers are left untouched, so data inside quotes is never reformatted.