DevWhat is a SQL formatter?
SQL that comes out of an ORM log, an application config file or a colleague's chat message is written in one breath: one enormous line where SELECT, FROM and WHERE blur together, or the opposite — a query exploded across forty lines by hand, every contributor with a different idea of where things line up. A SQL formatter (also called a beautifier or pretty-printer) rewrites the query with a consistent clause layout: each major clause starts on its own line, the item lists break one per line, and subqueries step in by one level — so the shape of the query, which tables feed which filters, is visible at a glance.
This one is deterministic: the same query always produces the same output, regardless of how the input happened to be wrapped. That makes formatted SQL safe to commit — diffs show real changes, not reflow noise — and safe to review, because the layout never depends on who pressed the button.
How to use this tool
- Paste your SQL into the box above (or press Load sample to see a worked example). You can also upload an .sql file or drop one onto the box — the file is read in your browser and never sent anywhere.
- Choose an indent — 2 spaces is the common default; 4 spaces and tabs are one click away.
- Press Format. The result appears below with a line count; your input above is never modified — the result is a separate copy.
- Tick Auto-format as I type if you would rather not press the button: the result updates as you edit (very large inputs are still formatted on demand, to keep typing smooth).
- Use Copy result or Download result to take the formatted query with you.
How the layout works
The formatter reads the query as a stream of tokens — words,
numbers, string literals, quoted identifiers, comments, operators
and parentheses — and reassembles it by clause. SELECT,
FROM, WHERE, GROUP BY,
ORDER BY, HAVING, LIMIT,
the JOIN family and the set operations
(UNION, INTERSECT,
EXCEPT) each begin a new line. Inside a WHERE
clause, AND and OR start their
own lines one level in, so long filter chains read as a list of
conditions instead of a paragraph. A parenthesised subquery is
indented as a block; ordinary parentheses — function calls, IN
lists, column lists — stay on the line, and a known function
name's parenthesis binds tightly (count(*), not
count (*)).
Clause keywords are uppercased wherever they appear as standalone
words — that includes AND, OR, NOT, NULL, AS and ON. Everything
else keeps the author's spelling: UserName stays
UserName, because in a case-sensitive collation that
can be a different column. String literals are opaque: the words
select and from inside
'a select from nowhere' are data, and the formatter
treats them that way.
Examples
This one-line query:
select u.name, o.total from users u left join orders o on o.user_id = u.id where o.total > 10 and u.active = 1 order by o.total descformats into:
SELECT u.name,
o.total
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.total > 10
AND u.active = 1
ORDER BY o.total DESCWhat this formatter does not do
Honest limits, in the open. This is a clause formatter, not a SQL parser: it does not validate your query, so a misspelled column or a missing comma passes through laid out but still wrong. CASE expressions, common table expressions and CREATE TABLE definitions are laid out by the same clause rules rather than given bespoke layouts, so their interiors stay on fewer lines than a hand-tuned format would use. And it formats for people, not for wire size — if you need the opposite direction, what you want is a minifier.