How to Format SQL Online (and Why Readable Queries Matter)
SQL formatting rewrites a query with consistent indentation, keyword casing, and line breaks so the logic is readable at a glance. The query runs identically before and after. Only the layout changes.
A one-line query like this is valid but hard to review:
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' group by u.id,u.email having count(o.id)>5 order by orders desc;
A formatter turns it into this:
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'
GROUP BY u.id, u.email
HAVING COUNT(o.id) > 5
ORDER BY orders DESC;
The second version makes the join condition, the filter, and the aggregate boundary obvious. That matters most during code review, where a misplaced WHERE or a join on the wrong column is the kind of bug formatting helps you catch.
What a SQL formatter changes
- Indentation for nested clauses and subqueries
- Keyword casing, usually uppercase for reserved words
- Line breaks before major clauses (
FROM,WHERE,GROUP BY,ORDER BY) - Comma placement in select lists and column groups
It never changes table names, column names, string literals, or query results. Formatting is purely cosmetic.
Dialect differences
SQL is not one language. A formatter that understands dialects handles syntax that would otherwise break naive tokenizing:
| Dialect | Syntax to watch |
|---|---|
| MySQL | Backtick-quoted identifiers `user` |
| PostgreSQL | Cast operator value::integer, dollar-quoted strings |
| SQL Server | Bracket identifiers [user] |
Pick the dialect that matches your database so quoted identifiers and casts survive formatting intact.
Format SQL without uploading it
You can format SQL in your browser with the free SQL Formatter. It runs entirely client-side, so queries that reference internal table and column names never leave your machine. Paste a query, pick MySQL or PostgreSQL, and copy the formatted result.
When to standardize formatting
Agree on one style per project and apply it consistently. The exact rules matter less than everyone using the same ones, because a consistent layout turns most diffs into single-line changes instead of whole-query rewrites. For shared repositories, run a formatter in a pre-commit hook so style never becomes a review topic.