What the SQL formatter does
The formatter takes a SQL statement — hand-written, copied from a log, or generated by an ORM as one enormous line — and lays it out with each clause on its own line and consistent indentation, so the structure is visible at a glance. The minify mode does the reverse, collapsing whitespace into a single line for embedding in code or pasting into a tool with a small input box. Formatting is purely textual and does not change what the query does. It runs in your browser, so queries containing table names or literal values are never sent anywhere.
Before and after
Before:
select u.id, u.email, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.created_at > '2026-01-01' and u.status = 'active' group by u.id, u.email having count(o.id) > 3 order by orders desc limit 50;
After:
SELECT u.id,
u.email,
COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2026-01-01'
AND u.status = 'active'
GROUP BY u.id, u.email
HAVING COUNT(o.id) > 3
ORDER BY orders DESC
LIMIT 50;Conventions the formatter applies
- Keywords uppercased — SELECT, FROM, WHERE, JOIN and friends, so they stand out from identifiers.
- One clause per line — each major clause starts a new line at the left margin.
- Conditions indented — AND / OR terms are indented under WHERE and HAVING.
- Selected columns on separate lines when there are several.
- Subqueries indented a level deeper than the clause containing them.
Identifiers, string literals and comments are left exactly as written — the formatter does not know your schema and does not try to guess.
Why format SQL at all
- Debugging — a 40-clause query on one line hides a missing JOIN condition; formatted, the mistake is obvious.
- Code review — reviewers can follow the logic and diffs show which clause changed.
- Reading ORM output — SQL logged by Django, Rails, Prisma or Hibernate is generated for the database, not for humans.
- Documentation — queries in runbooks and wikis should be readable years later.
- Consistency — a team that formats the same way spends less time arguing about style.
When to minify
Minified SQL is for machines: a query string constant in application code, a URL parameter to a reporting API, or a field in a YAML config. Databases do not care about whitespace, so minifying has no performance effect on execution — the only saving is a few bytes over the wire. Always keep the formatted version in source control and generate the minified one.
Dialect notes
| Dialect | Formats correctly? | Watch for |
|---|---|---|
| PostgreSQL | Yes | $$-quoted function bodies are treated as text |
| MySQL / MariaDB | Yes | Backtick identifiers preserved |
| SQLite | Yes | |
| SQL Server (T-SQL) | Mostly | Square-bracket identifiers preserved; procedural blocks (BEGIN…END) are laid out simply |
| Oracle PL/SQL | Partially | Package bodies and anonymous blocks are formatted as plain statements |
| BigQuery / Snowflake | Yes | Standard clauses; dialect-specific functions pass through |