SQL Formatter
Format SQL queries across 12 dialects — MySQL, PostgreSQL, SQL Server, BigQuery, Snowflake, and more. Configurable keyword case and indent. All in your browser.
About this tool
Clean SQL is the single biggest reviewability win for database code. A
query with consistent indentation, aligned joins, and uppercase keywords
can be read in seconds; the same query collapsed onto three lines takes
minutes to parse. This formatter handles twelve dialects — Standard SQL,
MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), SQLite, DuckDB, BigQuery,
Snowflake, Trino/Presto, Spark SQL, and Redshift — using the
sql-formatter library.
Dialect selection matters because keywords, functions, and syntax
extensions differ. PostgreSQL uses DATE_TRUNC where SQL
Server uses DATEADD/DATEFROMPARTS. MySQL escapes identifiers
with backticks while most other dialects use double quotes. BigQuery has
STRUCT literals and UNNEST; Snowflake has
QUALIFY. Pick the closest dialect and the formatter will
tokenize your query correctly, avoiding the common problem of
dialect-unaware formatters that break on unfamiliar keywords.
Use UPPER keywords when your team convention favors the traditional style — it dates back to when SQL was printed on paper and keywords needed to visually separate from data. Use lower for modern codebases where SQL is embedded in application code and readability benefits from looking like the surrounding language. Use preserve to keep the input’s existing case. Choose tab width to match the surrounding code style; 2 is common, 4 is traditional.
The Minify button collapses the query to a single line by stripping comments and excess whitespace. Useful for embedding SQL in scripts, stored procedures, or one-line command-line invocations. The output is functionally identical but not quite as safe as parameterized minification; if your SQL contains significant whitespace inside string literals, the simple collapse preserves them correctly, but unusual edge cases may need a manual review.
Frequently asked questions
What are the differences between dialects?
Each SQL dialect has its own keywords, function library, and syntax extensions. PostgreSQL understands window functions, CTEs, and types like JSONB. MySQL has backtick-quoted identifiers and its own string functions. SQL Server uses square brackets and TOP instead of LIMIT. BigQuery, Snowflake, and DuckDB add analytical functions and array/struct types. The formatter tokenizes using the dialect’s grammar so keywords are recognized and indented correctly.
Should I use UPPER or lowercase keywords?
Both are valid. UPPER keywords are the traditional convention (easier to scan in long queries) but lowercase has become popular in modern codebases — especially where developers want SQL to look like code. The choice matters less than consistency within a team. Use preserve to keep whatever the input already has.
Does formatting preserve comments?
Yes. Both line comments (-- comment) and block comments (/* comment */) are preserved in position. The formatter reindents them along with the surrounding code.
How does it handle very long queries?
The formatter uses a token-by-token parse, so query length is limited only by browser memory. Thousand-line queries format in a blink. If you have generated SQL in the hundreds of KB, expect a momentary pause but no error.
Can it format complex CTEs and window functions?
Yes. Common Table Expressions (WITH ... AS), window functions (OVER (PARTITION BY ... ORDER BY ...)), recursive CTEs, and LATERAL joins all format correctly when the dialect is set to a variant that supports them (Standard SQL, PostgreSQL, BigQuery, Snowflake, etc.).