SQL Formatter & Beautifier

Paste a cramped one-line SQL query and get back a readable, reviewable layout. Each major clause goes on its own line, recognised keywords are upper-cased, and long conditions and select lists wrap onto indented continuation lines — ideal for pull requests, documentation, and debugging.

What the formatter changes — and what it preserves

The formatter is a layout pass, not a parser:

1. Tokenise. The query is broken into tokens on whitespace, parentheses, and quote boundaries. Quoted strings and identifiers ('...', "...", `...`) are detected here and passed through untouched.
2. Line breaks. Major clauses — SELECT, FROM, WHERE, the JOIN family, GROUP BY, ORDER BY, LIMIT, and more — start a new line. AND/OR and commas in the SELECT list break onto indented continuation lines.
3. Casing. Only recognised keywords are upper-cased; your identifiers keep their original case.

Because it re-lays-out rather than validates, it will not flag syntax errors — but it also never changes what your query does.

Before and after examples

Simple SELECT:

Input:

select id, name, email from users where active = true and country = 'GB' order by name

Formatted (2-space indent):

SELECT
  id,
  name,
  email
FROM users
WHERE active = true
  AND country = 'GB'
ORDER BY name

Multi-join with GROUP BY:

Input:

select o.user_id, u.name, count(*) as orders, sum(o.total) as revenue from orders o inner join users u on u.id = o.user_id where o.status = 'completed' group by o.user_id, u.name having sum(o.total) > 500 order by revenue desc limit 20

Formatted:

SELECT
  o.user_id,
  u.name,
  COUNT(*) AS orders,
  SUM(o.total) AS revenue
FROM orders o
INNER JOIN users u ON u.id = o.user_id
WHERE o.status = 'completed'
GROUP BY o.user_id,
  u.name
HAVING SUM(o.total) > 500
ORDER BY revenue DESC
LIMIT 20

Note the string literal 'completed' and 'GB' are preserved exactly — only keywords change case.

When to use the formatter

• Before committing a migration file — consistent formatting makes diffs readable and avoids noise in code review.
• When debugging a query copied from ORM output — ORMs tend to emit dense single-line SQL; formatting makes the structure visible so you can spot a missing WHERE or a mistaken INNER JOIN.
• For documentation — formatted SQL in a README or API doc is far more readable than a minified query string.
• Code review — reviewers can read formatted SQL twice as fast as minified SQL; paste the formatted version into PR comments.

What it will not do

The formatter is a layout pass, not a semantic validator. It will not tell you if a column name exists, if a join condition is logically correct, or if there is a type mismatch. It will not reorder your clauses into the logical execution order. For validation, run the query against your database; for analysis, pair this with the SQL cheatsheet reference. Your query never leaves your browser.

Formatting conventions worth standardising on a team

The formatter enforces layout, but teams still choose the convention. The debates that actually matter:

• Keyword case. UPPERCASE keywords (SELECT, FROM) remain the most common convention because they visually separate structure from identifiers, though lowercase has grown with syntax-highlighted editors. Pick one; mixed case is the only wrong answer.
• Leading vs trailing commas. Leading commas (, column_b) make add/remove diffs one line and prevent the classic trailing-comma syntax error; trailing commas read more naturally. Style guides such as Simon Holywell’s SQL Style Guide document the trade-offs.
• Indent width and clause alignment. Consistent indentation of JOIN, ON and WHERE clauses is what makes a 40-line query reviewable in a pull request at all.

Dialects and the limits of “standard SQL”

SQL is standardised as ISO/IEC 9075, but every real database extends it (PostgreSQL documents its own conformance and syntax in detail in the PostgreSQL manual) — PostgreSQL’s :: casts, MySQL’s backtick quoting, T-SQL’s bracketed identifiers, BigQuery’s backtick-quoted project paths. A formatter must tokenise these without mangling them, which is why this tool formats conservatively: it normalises whitespace, line breaks and keyword casing but does not rewrite identifiers, literals or dialect-specific operators. The practical guarantee to care about: formatting must never change what the query does — a formatted query and its original must produce identical results, byte for byte, on every row. If you ever see otherwise, that is a bug to report, not a style choice.

Format before you review, not after you debug

The highest-value moment to format SQL is before code review: consistent layout makes the logic diff visible instead of a whitespace storm. The second-highest is when you inherit a legacy query — a 200-line vendor-generated statement collapsed onto three lines becomes tractable the moment each clause gets its own line. Format, then read, then refactor.

One more habit that compounds: format the query and keep the formatted version as the canonical one in your repository or saved-queries library. Teams that format ad hoc — each person reformatting to personal taste on touch — generate endless whitespace-only diffs; teams that store the formatted form once get clean history and reviewable changes from then on.