SQL Formatter & Beautifier

Why SQL Formatting Matters

A SQL query that works is not necessarily a SQL query that communicates. Raw, unformatted SQL — especially the kind copied from an ORM's debug output or a log file — collapses joins, conditions, and aggregations into a single dense wall of text that is nearly impossible to audit quickly. Compare these two queries that do the same thing:

-- Unformatted:
select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.status='completed' and o.total>100 order by o.created_at desc limit 20

-- Formatted:
SELECT u.id,
  u.name,
  o.total
FROM users u
INNER JOIN orders o
ON u.id = o.user_id
WHERE o.status = 'completed'
  AND o.total > 100
ORDER BY o.created_at DESC
LIMIT 20

The formatted version makes the query's intent immediately obvious: you can read the selected columns, understand the join relationship, and check each WHERE condition as a distinct logical step. In a code review, formatted SQL lets reviewers verify business logic in seconds rather than minutes.

Consistent formatting also makes version control diffs meaningful. When SQL is always formatted the same way, a commit that changes a single WHERE condition shows exactly one line changed — not a scrambled diff of whitespace changes mixed with logical changes.

Writing Readable SQL: Core Formatting Principles

The SQL community has converged on a small set of formatting principles that virtually all modern style guides agree on. Understanding these principles helps you decide when to apply them and why.

1. One clause per line

Major SQL clauses — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, LIMIT — each belong on their own line. This creates a natural left margin of clause keywords that acts as a table of contents for the query. A developer skimming the query can instantly see which clauses are present and jump directly to the one they need to examine.

2. Indent continuation lines

Items within a clause should be indented: column names after SELECT, filter conditions joined by AND or OR after WHERE. This indentation signals that these items are subordinate to the clause keyword above them. Two-space indentation is the most common choice; four spaces also works well.

3. Uppercase SQL keywords

Capitalizing reserved words (SELECT, FROM, WHERE, AND, CASE, etc.) while writing table and column names in lowercase is the dominant SQL convention for a good reason: it makes the structural skeleton of the query visible at a glance. The SELECT–FROM–WHERE pattern stands out from user-defined identifiers. GitLab's SQL style guide, the Mozilla SQL style guide, and most enterprise SQL linting tools all recommend uppercase keywords.

4. Spaces around operators

Comparison and arithmetic operators should have a space on each side: total > 100 rather than total>100. This is one of the most visually impactful formatting choices because it prevents conditions from blurring together, especially when multiple conditions appear in a single line.

Common SQL Formatting Mistakes (and How to Avoid Them)

Even developers who care about SQL formatting often make a few recurring mistakes. Here are the most common, along with the correct approach.

Putting AND/OR at the end of a line

Some style guides put AND at the end of the preceding line; others put it at the start of the next. The leading-AND style (shown in this formatter's output) is generally preferred because it makes it easy to comment out a single condition without breaking the query — you can comment the entireAND condition line and the query still parses correctly. Trailing-AND style requires editing two lines (removing AND from the preceding line) to safely disable a condition.

Writing deep subqueries inline

A WHERE clause that contains a nested subquery that itself contains another subquery becomes unreadable faster than almost anything else in SQL. The correct solution is not to format the nesting more carefully — it is to extract each subquery into a named CTE:

-- Hard to read (deep inline subquery):
SELECT * FROM products WHERE id IN (
  SELECT product_id FROM order_items WHERE order_id IN (
    SELECT id FROM orders WHERE user_id = 42 AND status = 'completed'
  )
)

-- Much clearer with CTEs:
WITH user_orders AS (
  SELECT id FROM orders WHERE user_id = 42 AND status = 'completed'
),
purchased_products AS (
  SELECT product_id FROM order_items WHERE order_id IN (SELECT id FROM user_orders)
)
SELECT * FROM products WHERE id IN (SELECT product_id FROM purchased_products)

Named CTEs serve as documentation — each intermediate result set has a name that describes its meaning, which makes the overall query self-documenting.

Inconsistent alias casing

If you alias a table as u in one query and U in another, SQL will handle it (most databases are case-insensitive for identifiers), but your teammates will have to do a mental mapping every time they read the query. Pick a consistent casing convention for aliases — typically lowercase single letters or short abbreviations — and stick to it across your codebase.

SQL Formatting in Team Environments

Individual developers formatting SQL consistently is good. A whole team doing it the same way automatically is much better. There are several tools that enforce SQL formatting at various points in the development workflow.

SQLFluff

SQLFluff is an open-source SQL linter and formatter that supports MySQL, PostgreSQL, BigQuery, Snowflake, Spark, dbt, and a dozen other dialects. It can be run as a pre-commit hook, in CI/CD pipelines, or integrated into editors. SQLFluff's configuration file lets teams define their exact style rules (indentation width, keyword case, comma placement) and enforce them automatically.

dbt's SQL formatting conventions

The dbt community has developed widely adopted SQL conventions, including the practice of using CTEs for all intermediate result sets, writing column lists with leading commas (so adding a column only requires adding one line), and defining all column aliases with the AS keyword. These conventions are opinionated but dramatically improve readability in data warehousing workloads where a single model may contain hundreds of lines of SQL.

When to format automatically vs. manually

Automated formatters work best for regular DML queries. For SQL embedded inside application code (Python, Java, TypeScript), automatic formatting of multi-line string literals is trickier and often requires format-on-save editor plugins. For ad-hoc queries run in a SQL IDE like DBeaver, TablePlus, or DataGrip, those tools have built-in formatters accessible with a keyboard shortcut. This online formatter is most useful for one-off queries, for formatting SQL you receive from others, or for cleaning up queries copied from log output.

Advanced SQL Patterns and How They Format

Modern SQL has grown far beyond the basic SELECT–FROM–WHERE trifecta. Here is how this formatter handles more advanced constructs.

Window functions

Window functions (OVER, PARTITION BY, ORDER BY within OVER) are handled as part of the SELECT clause. The PARTITION BY and ORDER BY inside an OVER clause are treated as part of the inline expression rather than top-level clauses, so they stay on the same line as the function call. For very long window function expressions, you can break them manually into CTEs for clarity.

CASE expressions

CASE … WHEN … THEN … ELSE … END expressions are common for conditional logic in SQL. When a CASE expression is short, keeping it on one line is fine. When it has multiple WHEN branches, formatting each WHEN on its own line with consistent indentation makes the branching logic much clearer — the same way if-else branches are formatted in general programming languages.

Multiple statements

This formatter handles multiple SQL statements separated by semicolons. Each statement is formatted independently, so you can paste a migration script containing CREATE TABLE, ALTER TABLE, and INSERT statements and get all of them formatted in a single pass. Each formatted statement is separated by a blank line for readability.

Frequently Asked Questions