How to use it
- Paste SQL — a single unreadable line is the expected input.
- Format breaks it onto clause boundaries; Minify collapses it back to one line.
- Keyword casing and indent width are adjustable.
What formatting actually does for you
SQL that arrives from an ORM log, a stack trace, or a colleague's message is one long line. Reading it means holding the clause structure in your head while scanning horizontally, which is why a 300-character query takes a minute to understand and a formatted one takes five seconds.
The formatter puts each major clause on its own line — SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY — and each join on its own. Select-list items and AND/OR conditions are indented under their clause, so the shape of the query becomes visible: how many joins, how many conditions, whether there is a subquery.
That shape is what you are usually looking for. A query with six joins and no WHERE clause is a problem you can see from across the room once it is formatted.
Why the tokeniser matters
The naive approach — find keywords and add newlines with a regular expression — breaks in a specific and dangerous way. Consider:
select * from logs where message = 'select from where order by'
A regex-based formatter mangles the string literal, and now the query means something different. The same applies to identifiers in quotes ("order" as a column name is legal in PostgreSQL) and to keywords appearing inside comments.
So this tool tokenises first: strings, quoted identifiers, -- line comments and /* */ block comments are recognised as single units and their contents are never inspected or altered. Only genuine keyword tokens outside those regions are touched.
Uppercase keywords, lowercase identifiers
The convention is old and worth following. SQL keywords are case-insensitive to the parser, so casing is purely for the reader — and the reader benefits from a visual distinction between the language and your schema:
SELECT u.id, u.display_name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o
ON o.user_id = u.id
WHERE u.is_active = TRUE
GROUP BY u.id, u.display_name
HAVING COUNT(o.id) > 3
ORDER BY order_count DESC
Identifiers stay in whatever case your schema uses. That distinction is not decorative: in PostgreSQL, unquoted identifiers fold to lowercase while quoted ones preserve case, so "UserName" and username are genuinely different columns. Leaving identifier casing alone is the only safe behaviour for a formatter.
One note on plan caching
Formatting changes the query text, and some databases key their plan cache on that text. SQL Server's plan cache and PostgreSQL's prepared statements both work this way, so reformatting a hot query can cause a single recompilation the first time the new text runs.
This is a one-off cost and not a reason to leave queries unreadable. It is worth knowing only because it occasionally shows up as a brief, unexplained latency spike right after a deploy that touched query strings.