How to format SQL queries that anyone can read

A messy SQL query is a query whose intent is hidden in punctuation. Formatting matters more in SQL than in most languages because the logic of the query — what joins to what, what filters apply where — is communicated entirely by structure.

The shape of a formatted query

Every formatted SQL statement follows the same pattern: major clauses start at column 0, sub-clauses are indented one level, and content within those clauses runs across one or many lines depending on length.

SELECT
  u.id,
  u.email,
  count(o.id) AS order_count
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at > '2026-01-01'
  AND u.deleted_at IS NULL
GROUP BY
  u.id,
  u.email
HAVING
  count(o.id) > 0
ORDER BY
  order_count DESC
LIMIT 50;

You can read this top to bottom: select these columns, from these tables joined this way, filtered by these conditions, grouped and ordered like so. The unformatted version is the same query — but you have to parse the punctuation to find the structure.

The SQL Formatter here applies that style automatically.

What gets standardised

Keyword case. SQL is case-insensitive but every team picks a convention. Three common ones: UPPERCASE keywords (loudly traditional, easy to scan), lowercase keywords (more modern, easier on the eyes), or preserve-what-was-typed (zero opinions). Pick one and stick to it across the codebase.

Indentation. Two-space indent is the modern default. Four-space comes from older style guides that mimicked Pascal / Ada conventions. The formatter supports both.

Comma style. This formatter puts commas at the end of lines — the "trailing comma" style. The alternative, "leading comma" (, u.email at the start of the next line), exists because it makes it easier to comment out a single column without breaking the syntax. Both work; trailing is more popular.

What the formatter does not do

It does not validate the query. The formatter is a string transformer, not a parser. If you have a syntax error, the formatter will reshape your invalid SQL into invalid SQL with better indentation.

It does not rewrite logic. Joins stay joins. Subqueries stay subqueries. WHERE x = 1 OR x = 2 does not become WHERE x IN (1, 2). The formatter changes shape, not semantics.

It does not handle every dialect's superpowers. Standard SQL works fine. PostgreSQL-specific operators (@>, ->), MySQL's backtick identifiers, Snowflake's STAGE, BigQuery's UNNEST — all pass through but may not get bespoke indentation. Re-check those manually for your project.

A workflow that scales

For one-off queries: paste, format, copy, share. Done in five seconds.

For team consistency: agree on keyword case + indent size, format every query before code review. The diff between "what I typed" and "what was agreed" is the diff you actually care about reviewing.

For long-term maintenance: keep raw queries formatted in version control. Every diff after that highlights real logic changes instead of accidental whitespace shifts. Future you, reviewing your own SQL six months from now, will be grateful.