How to format SQL.
Without changing what it means.

What a formatter does, and what it must never do

A SQL formatter rewrites whitespace: keyword case, indentation, line breaks around clauses. It does not change the query. The part that matters is the second half of that sentence — a formatter that alters case inside a quoted identifier, reorders a WITH clause, or rewrites a string literal has changed the query, not formatted it.

That is not a hypothetical. In PostgreSQL and in standard SQL, "UserID" is a different identifier from "userid" — the case inside the quotes is part of the name. Lowercasing it breaks the query, and the error arrives as "column does not exist" rather than "the formatter changed something". The same goes for string literals: 'Smith' is data, and a formatter that turns it into 'smith' has edited a customer’s name.

Keyword case: pick one and keep it

There is no correct answer. Uppercase keywords (SELECT, FROM) read as SQL rather than as English; lowercase (select, from) read as prose. Both are used in large codebases. The only wrong choice is a file with both.

One thing worth knowing: most editors and formatters can change only the keywords and leave identifiers and strings alone, because those are the parts the parser has marked. A formatter that does not distinguish them is going to bite you eventually, whatever its casing rule.

The dialect differences that catch people out

That is why the formatter here asks which dialect you are writing in: it changes how it quotes identifiers and how it treats the date and string syntax, not just the whitespace. SQL Server adds a fourth set of differences — TOP 10 instead of LIMIT, and square brackets for identifiers.

The join is where the readability is won or lost

Most unreadable SQL is not badly indented SQL, it is a query where six tables are joined and you cannot tell which condition belongs to which join. Putting each JOIN on its own line with its ON condition indented under it turns a wall into a list:

SELECT o.id, c.name, t.total
FROM orders o
JOIN customers c
  ON c.id = o.customer_id
JOIN (
  SELECT order_id, SUM(amount) AS total
  FROM order_lines
  GROUP BY order_id
) t
  ON t.order_id = o.id
WHERE o.created_at >= DATE '2026-01-01'
ORDER BY t.total DESC;

Two habits do most of the work. Give every table an alias, and never leave a join without its ON on the line below it. Aliases also stop customer_id and shipping_customer_id from looking identical, which is where the real bugs live.

Long queries: break them where a human reads

Keep lines under about 100 characters, and break a SELECT list one column per line when there is more than a handful. A common and readable shape:

SELECT
  o.id,
  o.created_at,
  c.name AS customer_name
FROM orders o
JOIN customers c
  ON c.id = o.customer_id
WHERE o.status = 'paid'

Subqueries in the FROM clause, like the total above, are worth converting to a WITH block when they are reused or complicated. A WITH clause is not faster, but it gives a name to the thing you are computing, and the name is what the next reader needs.

Running it

The SQL formatter parses the query and rewrites it in the browser, with a dialect selector for standard SQL, PostgreSQL and MySQL. It shows the formatted result next to the original so you can see exactly what changed, and nothing leaves your machine — which matters more than it sounds, because a WHERE clause can hold a customer name, a phone number or an internal ID.

Two things to check after formatting a query you care about: that the row count is the same, and that the query still explains itself. Formatting is not a review, and a formatter will happily make a wrong query look tidy.