SQL Formatter

Format and beautify SQL queries

SQL Dialect

Uppercase keywords

Understanding SQL Formatting

TL;DR

SQL formatting applies consistent indentation, capitalization, and line breaks to SQL queries. Readable SQL is debuggable SQL.

What is SQL Formatting?

SQL formatting is the practice of applying consistent indentation, line breaks, capitalization, and spacing to SQL queries. While the SQL engine ignores whitespace and treats SELECT and select identically, human readers do not. A well-formatted query communicates its intent at a glance; a poorly formatted one hides bugs.

SQL is often the longest, most complex code that developers write without the benefit of an IDE’s auto-formatter. Queries of 50, 100, or even 500 lines are common in analytics, data engineering, and backend development. Without consistent formatting, these queries become nearly impossible to review, debug, or maintain.

A SQL formatter automates this process — it takes any syntactically valid SQL and restructures it according to a set of rules, producing clean, consistent output regardless of how the input was written.

Common SQL Formatting Conventions

While there is no single universal SQL style guide, most teams converge on similar conventions:

Keyword Capitalization

Style	Example	Prevalence
UPPERCASE keywords	`SELECT id FROM users WHERE active = 1`	Most common
lowercase keywords	`select id from users where active = 1`	Common in ORMs
Title Case	`Select id From users Where active = 1`	Rare

Uppercase keywords are the dominant convention in the SQL community. They create a clear visual distinction between SQL structure (SELECT, FROM, WHERE, JOIN) and user-defined identifiers (table names, column names, aliases).

Indentation and Line Breaks

Standard formatting rules include:

Major clauses on new lines: Each SQL clause (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT) starts on a new line at the base indentation level.
Column lists indented: Each column in a SELECT clause gets its own line, indented one level.
JOIN conditions indented: The ON clause of a JOIN is indented under the JOIN keyword.
WHERE conditions aligned: Multiple conditions in a WHERE clause are indented and prefixed with AND or OR at the start of each line.
Subqueries indented: Subqueries are indented one additional level and wrapped in parentheses on their own lines.

Aliases

Use short, meaningful table aliases (users u or users AS u)
Prefix all column references with the table alias when multiple tables are involved
Place AS keyword explicitly for clarity (optional but recommended)

Dialect Differences

SQL is not a single language — it is a family of dialects. Each database engine extends the SQL standard with proprietary syntax, and formatters must account for these differences:

Feature	PostgreSQL	MySQL	SQL Server	BigQuery
String quoting	`'text'`	`'text'` or `"text"`	`'text'`	`'text'`
Identifier quoting	`"column"`	`column`	`[column]`	`column`
LIMIT syntax	`LIMIT 10`	`LIMIT 10`	`TOP 10`	`LIMIT 10`
Boolean type	`TRUE/FALSE`	`1/0`	`1/0`	`TRUE/FALSE`
UPSERT	`ON CONFLICT`	`ON DUPLICATE KEY`	`MERGE`	`MERGE`
CTE support	Full	8.0+	Full	Full

When configuring a SQL formatter, always specify the target dialect. A formatter configured for PostgreSQL may produce invalid syntax for MySQL and vice versa. Modern formatters support multiple dialects and can switch between them.

Formatting Best Practices

Beyond the basic conventions, experienced SQL developers follow additional practices:

One statement per line for DDL: CREATE TABLE, ALTER TABLE, and CREATE INDEX statements benefit from one column definition per line.
CTEs (WITH clauses) first: Place Common Table Expressions at the top of the query, each with a descriptive name, before the main SELECT.
Consistent comma placement: Either leading commas (,name) or trailing commas (name,) — pick one and stick with it. Leading commas make it easier to comment out columns.
Meaningful aliases: Avoid single-letter aliases for complex queries. Use ord instead of o when the query spans 50+ lines.
Comment complex logic: Add inline comments (-- explanation) for non-obvious WHERE conditions, calculations, or business rules.

Common Use Cases

Code review: Formatted SQL is dramatically easier to review in pull requests. Reviewers can spot missing JOIN conditions, incorrect WHERE logic, and performance issues at a glance.
Debugging: When a query returns unexpected results, consistent formatting helps isolate the problem clause by clause.
Documentation: Formatted queries in documentation, wikis, and runbooks are more accessible to team members who did not write them.
Migration scripts: Database migration files (Flyway, Liquibase, Alembic) benefit from consistent formatting for auditability and rollback clarity.
Analytics and reporting: Data analysts working with long analytical queries rely on formatting to manage complexity across multi-table joins, window functions, and nested subqueries.

Try These Examples

Well-Formatted SELECT with JOINs Valid

A properly formatted query with uppercase keywords, consistent indentation, one column per line in the SELECT clause, and aligned JOIN/WHERE conditions. This style is immediately scannable.

SELECT
  u.id,
  u.name,
  o.total_amount
FROM users u
INNER JOIN orders o
  ON o.user_id = u.id
WHERE u.active = 1
  AND o.created_at >= '2024-01-01'
ORDER BY o.total_amount DESC
LIMIT 100;

Unformatted Single-Line Query Valid

Syntactically valid SQL that produces the same result, but compressed onto a single line with inconsistent casing. Extremely difficult to read, debug, or review in a code review context.

select u.id,u.name,o.total_amount from users u inner join orders o on o.user_id=u.id where u.active=1 and o.created_at>='2024-01-01' order by o.total_amount desc limit 100;