SQL Formatter

What is SQL formatting?

SQL is whitespace-insensitive. SELECT a,b FROM t WHERE x=1 and a version with consistent indentation and line breaks are the same query. But they are not equally readable. Formatting is the act of adding whitespace to make the structure of the query visible: clauses on their own lines, join conditions aligned, subqueries indented, and so on.

Most teams format SQL for three reasons: so reviews can spot logic errors quickly, so diffs are minimal when someone changes a query, and so long queries do not need to be mentally re-parsed every time they are read.

How to use

Paste a query. Choose a dialect, keyword case, and indent width. The output updates live.

Options:

• Dialect - which SQL variant to parse. Affects which keywords are recognized and how constructs like LIMIT/TOP, backtick versus double-quote identifiers, and vendor-specific functions are handled.
• Keyword case - uppercase (SQL standard, most common), lowercase, or preserve as typed.
• Indent - 2, 4, or 8 spaces.
• Lines between queries - when formatting a script with multiple statements, how many blank lines to insert between them.

Supported dialects

19 SQL dialects are supported. The most common:

• Standard SQL - the ISO/ANSI base. Use if unsure and none of the vendor-specific keywords appear.
• PostgreSQL - default for Postgres, Redshift, and most derivatives.
• MySQL / MariaDB - backtick identifiers, LIMIT syntax.
• SQLite - close to standard, with some quirks.
• Transact-SQL (T-SQL) - SQL Server and Azure SQL. TOP instead of LIMIT.
• BigQuery - Google Cloud, backtick-quoted identifiers, array and struct syntax.
• Snowflake - includes the QUALIFY clause and semi-structured types.
• Redshift - AWS data warehouse, PostgreSQL-derived with extensions.
• DuckDB - growing in popularity for analytics.
• Trino / Presto - distributed query engine.

Also supported: Db2, Db2 for i, Hive, N1QL (Couchbase), PL/SQL (Oracle), SingleStoreDB, Spark SQL, TiDB.

If none of the specialized keywords in your query matter, choosing the wrong dialect usually still produces reasonable output. The dialect mainly matters when the query contains syntax that is unique to one vendor.

Keyword case

Uppercase is the SQL standard and the most common convention. Reserved words stand out against identifiers and string literals, which makes the structure of the query easier to scan. This is the default in most style guides, including the one used by PostgreSQL documentation.

Lowercase is preferred by some teams and is the default in a few ecosystems (notably some ORMs). It has the same readability benefit as uppercase, just with inverted visual weight.

Preserve leaves keywords exactly as you typed them. Useful when formatting a query that you do not want to change beyond whitespace.

FAQ

Does formatting change what the query does?

No. SQL is whitespace-insensitive outside of string literals. Formatting only adds or moves whitespace, which has no semantic effect. The one case to be careful about is when a query contains a string literal with significant whitespace - formatting does not touch the inside of string literals, so this is safe.

Will comments be preserved?

Yes. Both line comments (--) and block comments (/* */) are preserved. Their position may shift slightly to align with the formatted structure.

What if my query uses non-standard syntax?

Try a different dialect. Most proprietary extensions appear in at least one of the supported dialects. If the formatter errors, the message usually points to the specific token or clause it did not recognize.

Can I format multiple statements at once?

Yes. Statements separated by semicolons are formatted independently and joined with the number of blank lines you choose. This is useful for formatting migration files and stored procedures.

Does it validate the query?

No. It parses the query enough to know where the clauses are, but it does not check table names, column names, or referential integrity. A syntactically valid query that refers to non-existent tables will format fine.

How does this compare to pg_format, sqlfluff, or sqlfmt?

pg_format is Postgres-specific and written in Perl. sqlfluff is a linter first and a formatter second - it enforces a style guide and reports violations. sqlfmt is opinionated and targeted at dbt workflows. This tool uses sql-formatter, which is a pure formatter: it rearranges whitespace and nothing else, and it supports more dialects than any of the alternatives.