SQL Formatter — Complete Guide
Why Formatting SQL Matters
SQL is written far more often than it is created by hand — it's generated, pasted from logs, dumped by ORMs, and copied between tools. The result is usually one long line that is technically valid and practically unreadable. Formatting SQL matters because readability is correctness: a query you can scan top-to-bottom is a query you can debug, review, and trust. Unformatted SQL hides missing joins, misplaced parentheses, and logic errors that a clear layout makes obvious in seconds.
Formatting also matters for collaboration. When a teammate can tell at a glance which columns come from which table and where each clause begins, code reviews get faster and onboarding gets cheaper. Teams that adopt a consistent SQL style spend noticeably less time asking "what does this query actually do?"
Common SQL Style Conventions
There is no single official SQL style, but a few conventions are so widespread they're effectively standard:
- Uppercase keywords —
SELECT,FROM,WHERE,JOINin caps so they stand out from column names. - One clause per line — each major keyword starts a new line.
- Consistent indentation — 2 or 4 spaces for continued expressions and join conditions.
- Commas at the start of lines (or end — pick one and stay consistent) so added columns are one-line diffs.
- Explicit aliases — short, meaningful aliases qualified on every column.
- Consistent quoting — lowercase identifiers, single quotes for string literals, avoid reserved words as names.
Before and After: See the Difference
Here's the same query unformatted:
SELECT u.id,u.name,o.total FROM users u JOIN orders o ON o.user_id=u.id WHERE o.status='paid' AND u.country IN ('US','UK') ORDER BY o.total DESC LIMIT 10;
And here it is after formatting:
SELECT
u.id,
u.name,
o.total
FROM users u
JOIN orders o
ON o.user_id = u.id
WHERE o.status = 'paid'
AND u.country IN ('US', 'UK')
ORDER BY o.total DESC
LIMIT 10;
The second version makes the query's structure visible: three columns selected, one join on a user id, two filters, one sort. You can now reason about the execution order and spot problems — like a missing WHERE filter on a reporting query — without squinting.
Beautify vs Minify
A good SQL formatter offers two modes for different jobs:
- Beautify (format) — expands the query into the readable layout above. Use it for code review, documentation, debugging, and anything a human will read.
- Minify — compresses the query to one line, stripping optional whitespace and comments. Use it for storage, logs, and anywhere size or line-count matters, like fitting a query into a single configuration value.
Both should preserve the query's meaning exactly. If a formatter changes what the query does — beware naive tools that mangle string literals containing SQL — it's broken, not helpful.
Formatting Complex Queries
Formatting pays off most on big queries. Subqueries, CTEs, and CASE expressions become navigable when each level is indented:
WITH paid_orders AS (
SELECT user_id, SUM(total) AS revenue
FROM orders
WHERE status = 'paid'
GROUP BY user_id
)
SELECT
u.name,
p.revenue,
CASE
WHEN p.revenue > 500 THEN 'high'
ELSE 'standard'
END AS tier
FROM users u
JOIN paid_orders p
ON p.user_id = u.id
ORDER BY p.revenue DESC;
Notice how the CTE body and the CASE branches are each indented one level deeper than the clauses that contain them. That visual hierarchy is exactly what a formatter automates, so you never have to align anything by hand.
What to Look for in a SQL Formatter
Not all formatters are equal. The good ones let you control indentation width, keyword case, and where commas and line breaks land, so the output matches your team's existing style instead of fighting it. They should also preserve comments, handle string literals that contain SQL-looking text, and leave the query's logic completely untouched. A formatter that rewrites your operators or collapses your comments is more dangerous than no formatter at all.
Beyond the basics, useful extras include dialect awareness (MySQL vs PostgreSQL vs SQLite quirks), the ability to format just a selected snippet, and a minify mode for compact storage. If you work with generated queries — the kind ORMs and BI tools produce — a formatter with these options turns unreadable one-liners into queries your whole team can maintain.
Try It Live
Stop hand-aligning queries. Paste any SQL — messy, generated, or copied from logs — into our free SQL Formatter and get clean, consistent output instantly, with options for indentation size, keyword case, and minify mode.
FAQ
Can formatting change what my query does?
No. Whitespace, line breaks, and keyword case don't affect SQL semantics. A reliable formatter only touches layout, never the query's logic or string contents.
Should keywords be uppercase or lowercase?
Either works — it's purely convention. Uppercase keywords are the most common style because they make the query structure jump out from column names, which are almost always lowercase.
What is minified SQL used for?
Minified SQL is compact single-line text — handy for storing queries in config files, logs, or database columns where readability isn't needed, and for keeping diffs small. Keep a formatted copy for anything you'll debug.