T
sql format beautify database developer-tools

SQL Formatter: Beautify and Format Your SQL Queries Instantly

Improve the readability of your SQL queries with our online SQL formatter. Easily format, beautify, and clean up complex database scripts.

2026-04-09 Use This Tool

Introduction

Every developer who works with databases has encountered a wall of unformatted SQL: keywords in lowercase, no line breaks, table names smashed against JOIN conditions, all on a single line scrolling endlessly to the right. It is nearly impossible to debug, review in a pull request, or hand off to a colleague. SQL formatting is not merely cosmetic — it is a professional discipline that improves readability, reduces bugs, enforces team standards, and makes maintenance dramatically easier.

Whether you are writing a five-line SELECT or a hundred-line analytics pipeline with CTEs and window functions, consistent formatting is the difference between code that communicates intent and code that obscures it.

A Brief History of SQL

SQL was born in the early 1970s at IBM's San Jose Research Laboratory, where Edgar F. Codd's relational model inspired Donald D. Chamberlin and Raymond F. Boyce to develop a language called SEQUEL (Structured English Query Language). It was later renamed SQL. IBM shipped it in System R, and Oracle became the first company to sell a commercial SQL database in 1979.

The American National Standards Institute (ANSI) published the first SQL standard in 1986, followed by ISO ratification. Subsequent revisions — SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011, SQL:2016 — progressively added features like triggers, stored procedures, recursive queries (CTEs), window functions, and JSON support.

Despite the standard, every major database vendor introduced proprietary extensions, giving rise to dialects: MySQL, PostgreSQL, Microsoft SQL Server (T-SQL), SQLite, Oracle PL/SQL, and others. These dialects share a common core but differ in syntax for string operations, date functions, identity columns, and more.

SQL Syntax Basics

Before formatting, it helps to understand the building blocks. A standard SELECT statement follows this logical order:

SELECT   -- columns to return
FROM     -- source tables
JOIN     -- related tables
WHERE    -- row-level filters
GROUP BY -- aggregation grouping
HAVING   -- aggregate-level filters
ORDER BY -- sort order
LIMIT    -- row count restriction

Each clause has a distinct purpose. WHERE filters before aggregation; HAVING filters after. GROUP BY collapses multiple rows into one per group. ORDER BY applies last (before LIMIT). Understanding this order helps you format queries so each clause starts on its own line, making the logical flow immediately visible.

Formatting Conventions

There is no single universal standard, but the following conventions are widely adopted:

Keyword Capitalization Most style guides recommend writing SQL keywords (SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT) in UPPERCASE. This provides visual contrast between structural keywords and user-defined identifiers. Some modern teams prefer lowercase for aesthetics, and tools like dbt have popularized that style. The key rule: be consistent.

Indentation Use 4 spaces (or 2 spaces in compact styles) to indent column lists, ON clauses, and WHERE predicates. Tabs should be avoided in shared codebases due to inconsistent rendering across editors.

Line Breaks Each major clause (SELECT, FROM, WHERE, GROUP BY, etc.) should begin on its own line. Column lists in SELECT should be placed one per line, indented under the keyword. This makes it easy to add, remove, or comment out individual columns.

Comma Placement There are two camps: trailing commas (end of line) and leading commas (start of next line). Trailing commas are more natural for most programmers; leading commas make it easier to spot a missing comma at a glance. Choose one and stick to it.

Aliasing Always use the AS keyword when aliasing (u AS user, not u user). This makes the intent explicit and avoids ambiguity in complex queries.

Before and After: A Formatting Example

-- BEFORE (unformatted)
select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.total>100 and u.active=1 order by o.total desc limit 10

-- AFTER (formatted)
SELECT
    u.id,
    u.name,
    o.total
FROM
    users u
    INNER JOIN orders o ON u.id = o.user_id
WHERE
    o.total > 100
    AND u.active = 1
ORDER BY
    o.total DESC
LIMIT 10

The formatted version makes the table relationship, filter conditions, and sort order immediately scannable.

SQL Dialects Comparison

While SQL is standardized, dialects differ in important ways:

Feature MySQL PostgreSQL SQL Server SQLite
String concat CONCAT() ` orCONCAT()`
Auto-increment AUTO_INCREMENT SERIAL / IDENTITY IDENTITY AUTOINCREMENT
Limit rows LIMIT n LIMIT n TOP n LIMIT n
Date functions DATE(), NOW() CURRENT_DATE, NOW() GETDATE() DATE()
Case sensitivity Default: insensitive Default: sensitive Default: insensitive Configurable

Understanding these differences is critical when porting queries between databases. A formatter that knows the target dialect can produce syntactically valid output even for dialect-specific constructs.

SQL Style Guides

Two widely referenced style guides help teams establish consensus:

SQL Style Guide by Simon Holywell (sqlstyle.guide) This guide emphasizes root word alignment, using rivers of whitespace to visually separate clauses, leading commas, and snake_case for identifiers. It is opinionated but thorough and widely used in data engineering teams.

Google SQL Style Guide Google's internal style guide (partially public via BigQuery documentation) favors trailing commas, 4-space indentation, UPPERCASE keywords, and wrapping long IN lists. It aligns well with the Java coding standards familiar to many Google engineers.

Most teams create a lightweight internal style guide derived from one of these and enforce it via automated formatting in CI pipelines.

How SQL Formatters Work

A SQL formatter is, at its core, a specialized compiler front-end. The process involves three stages:

1. Lexing (Tokenization) The raw SQL string is broken into a flat stream of tokens: keywords (SELECT, FROM), identifiers (users, u), operators (=, >), literals ('completed', 100), punctuation (,, ;), and whitespace/comments. The lexer does not understand structure — it only classifies characters.

2. Parsing The token stream is fed into a parser that builds an Abstract Syntax Tree (AST). Each node represents a logical construct: a SelectStatement node contains a ColumnList node, a FromClause node, a WhereClause node, and so on. The parser enforces grammar rules and detects syntax errors.

3. Re-emission (Pretty Printing) The formatter walks the AST and emits SQL text according to formatting rules: newlines after clause keywords, indentation for child nodes, spaces around operators, keyword casing transformations. Because the output derives from the AST, the semantic meaning of the query is preserved perfectly.

Some simpler formatters skip full AST construction and apply rule-based transformations on the token stream directly. These are faster but less accurate for complex nested structures.

Common SQL Patterns with Examples

Multi-Table JOIN

SELECT
    c.name AS customer_name,
    p.name AS product_name,
    oi.quantity,
    oi.unit_price
FROM
    customers c
    INNER JOIN orders o ON c.id = o.customer_id
    INNER JOIN order_items oi ON o.id = oi.order_id
    INNER JOIN products p ON oi.product_id = p.id
WHERE
    o.status = 'shipped'
    AND o.created_at >= '2024-01-01'
ORDER BY
    c.name,
    o.created_at DESC;

Subquery

SELECT
    department,
    AVG(salary) AS avg_salary
FROM employees
WHERE salary > (
    SELECT AVG(salary)
    FROM employees
)
GROUP BY department
ORDER BY avg_salary DESC;

CTE (Common Table Expression)

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', created_at) AS month,
        SUM(amount) AS revenue
    FROM orders
    WHERE status = 'completed'
    GROUP BY 1
),
ranked_months AS (
    SELECT
        month,
        revenue,
        RANK() OVER (ORDER BY revenue DESC) AS rank
    FROM monthly_revenue
)
SELECT *
FROM ranked_months
WHERE rank <= 3;

CTEs improve readability by breaking complex queries into named, reusable building blocks. They are especially valuable in analytics SQL where intermediate aggregations feed into further calculations.

Window Functions

SELECT
    employee_id,
    department,
    salary,
    AVG(salary) OVER (PARTITION BY department) AS dept_avg,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank
FROM employees;

Window functions (ROW_NUMBER, RANK, LAG, LEAD, SUM, AVG with OVER) are among the most powerful SQL features. Proper formatting — each OVER clause on the same line as its function — is essential for readability.

Aggregation with HAVING

SELECT
    category,
    COUNT(*) AS total_products,
    AVG(price) AS avg_price,
    MAX(price) AS max_price
FROM products
WHERE active = 1
GROUP BY category
HAVING COUNT(*) > 10
ORDER BY avg_price DESC;

Integration with IDEs and Tools

VS Code The sql-formatter npm package powers several VS Code extensions. Configure format-on-save in settings.json:

"[sql]": { "editor.defaultFormatter": "mtxr.sqltools" }

JetBrains DataGrip DataGrip has built-in SQL formatting under Code → Reformat Code (Ctrl+Alt+L). Style options are configurable per data source dialect under Settings → Editor → Code Style → SQL.

DBeaver DBeaver supports SQL formatting via SQL Editor → Format SQL and allows custom formatter configuration in Preferences → Editors → SQL Editor → Formatting.

dbt The sqlfmt tool was created specifically for dbt projects and enforces a consistent lowercase style optimized for version control diffs.

Command Line The sql-formatter npm package can be used as a CLI tool:

npx sql-formatter --language postgresql --indent 4 query.sql

Best Practices

  1. Format early, format often. Run the formatter before every commit, not just before code review.
  2. Agree on a style guide first. No formatter can substitute for team consensus on conventions.
  3. Use aliases consistently. Short aliases (1-2 letters) are fine for simple queries; descriptive aliases improve readability in complex ones.
  4. Name CTEs descriptively. monthly_revenue is better than cte1 or tmp.
  5. Comment complex logic. A well-formatted query with inline comments explaining non-obvious business rules is far more maintainable than clever but silent SQL.
  6. Lint SQL in CI. Tools like sqlfluff can enforce formatting rules automatically in pull request pipelines.
  7. Keep CASE WHEN readable. Split long CASE WHEN chains across multiple lines, one branch per line.
  8. Qualify all column references. In multi-table queries, always prefix column names with the table alias (u.id not just id).

Frequently Asked Questions

Does formatting change the behavior of my query? No. A formatter only changes whitespace, line breaks, and keyword casing. The logical structure and execution plan remain identical.

Can a formatter fix syntax errors? No. Formatters require syntactically valid SQL to parse correctly. Use a linter like sqlfluff to detect and explain errors.

Which keyword casing style should I use? UPPERCASE for keywords is the traditional and most widely recommended convention. However, lowercase is increasingly popular in dbt and modern data tooling. Pick one for your team and enforce it automatically.

Does it support stored procedures and PL/SQL blocks? Support varies. Most formatters handle DML (SELECT, INSERT, UPDATE, DELETE) well. Procedural extensions require dialect-aware parsers and vary in support quality.

Is my SQL data safe when using online formatters? A good online formatter processes everything client-side in the browser using JavaScript. Your query never leaves your machine. Always verify this in the tool's privacy policy before pasting sensitive schema information.

What is the difference between a formatter and a linter? A formatter transforms the presentation of SQL without changing its meaning. A linter (sqlfluff, SQLCheck) analyzes SQL for style violations, anti-patterns, and potential bugs, reporting issues rather than auto-fixing them.

Back to Blog SQL Formatter →