Skip to content
TypeParser
All tools

SQL Formatter

Format SQL for any warehouse dialect.

beats sqlformatter.org edge: Warehouse-dialect profiles + tabular align
input.sql
formatted
dialect case indent
paste SQL to format
Guide

About SQL Formatter

Format SQL with the rules of your target warehouse. Pick dialect (Snowflake, BigQuery, Postgres, MySQL, SQLite, Databricks), keyword case (UPPER, lower, Title), indent width, and whether SELECT lists tabular-align by column. Comments and string literals are preserved. Everything runs locally.

What a good SQL formatter changes

Whitespace, indentation, keyword case. Nothing else. The query is byte-different in casing and layout, semantically identical, faster for a human to read in a code review.

A bad formatter breaks queries: mishandles CTEs, swallows comments, normalizes quote styles in literals. Ours parses the SQL into an AST first, formats from the AST, and refuses to emit anything if parsing fails — so you always see a precise error before any output.

Dialect-aware behavior

DialectSpecial handling
SnowflakeQUALIFY, IDENTIFIER, semi-structured operators (:, [])
BigQuerySTRUCT, ARRAY, backtick identifiers, EXCEPT (col_list)
PostgresRETURNING, LATERAL, custom operators, dollar-quoted strings
MySQLBacktick identifiers, ON DUPLICATE KEY UPDATE
SQLiteLighter keyword set, no schema-qualified names
DatabricksDelta-specific keywords, CLUSTER BY

Pick the dialect that matches your codebase and the formatter outputs idiomatically.

Common workflows

Clean up a query before code review. Drop the messy SQL, format, paste back. The reviewer reads structure, not whitespace.

Standardize keyword case across a repo. Format every query through the same settings, commit. Diffs become noise-free for the next month.

Translate copy-pasted vendor docs. Vendors love uppercase keywords in marketing pages. Format with lowercase to match your codebase before pasting.

Inspect generated SQL. ORMs emit SQL you have never read. Format it. Now you can reason about what your code actually runs.

Why warehouse-aware formatting wins

Generic formatters work, but the output looks “almost right” to engineers fluent in their warehouse. Snowflake teams expect QUALIFY to indent like WHERE. BigQuery teams expect backtick identifiers preserved. Postgres teams expect dollar-quoting untouched. Tying the formatter to the dialect produces output that lands as native, not translated.

Frequently asked questions

Why does dialect matter for formatting?
Each warehouse has its own keyword set, function names, and idiomatic structure (CTEs, MERGE INTO, QUALIFY). A formatter that knows the dialect produces output that matches the codebase style guide of teams working in that warehouse.
Will it break my CTE?
No. The formatter parses before formatting. Common Table Expressions, window functions, lateral joins, recursive CTEs, MERGE statements — all preserved structurally; only whitespace and case change.
What is tabular alignment?
SELECT lists where every column starts at the same indent column. Easier to scan in code review. Toggle the option to enable.
Does it handle comments?
Yes. Both -- and /* */ styles. Inline comments stay on their line; block comments preserve internal layout.
Why does my formatter normalize <code>'string'</code> quotes?
It does not. String literals are byte-preserved. Only keyword case and whitespace are touched.
Can it minify SQL?
A bit — the format/minify toggle collapses whitespace and inline comments. For aggressive minification (variable rewriting, alias shortening), use a real query optimizer.

Related tools

Last updated: 2025-01-15