About the SQL Formatter
Queries arrive as a single line. An ORM logged it, a colleague pasted it out of a dashboard, it grew a clause at a time until nobody could read it.
Formatting puts each clause on its own line and indents the structure. It can make structure easier to review. Always review the output before running a query.
The errors that only show up once it is laid out
SQL mistakes are mostly structural, and structure is exactly what a single line hides.
A missing join condition is the expensive one. Two tables in the FROM clause with nothing connecting them produces a cross product - every row of one against every row of the other. It runs, it returns data, and on small test tables it can even look plausible. Laid out with each join on its own line, a join with no ON clause is immediately obvious.
Operator precedence in a WHERE clause is the subtle one. AND binds tighter than OR, so a condition written as A AND B OR C means (A AND B) OR C, not A AND (B OR C). On one line the intent is invisible; formatted and indented, the grouping is something you can actually check.
Then there is a GROUP BY that does not cover every non-aggregated column - some databases reject it, others pick a value arbitrarily - and a LIMIT applied to a query where the ORDER BY makes the result non-deterministic.
None of these are syntax errors. They all execute. They return the wrong rows, which is much worse than failing.
- A join with no ON clause - you have written a cross product.
- AND and OR mixed without brackets - precedence is probably not what you meant.
- GROUP BY missing a selected column.
- LIMIT without a deterministic ORDER BY - the rows you get can vary between runs.
Formatting is not validation
Unlike JSON, where laying it out proves the syntax is correct, a SQL formatter works from a fairly shallow reading of the text.
It will happily format a query referencing a table that does not exist, a column misspelled, or a function belonging to a different database engine. Clean output is not proof of valid SQL or equivalent behavior. It does not mean the query runs.
The only way to know a query works is to run it - against a copy, with a LIMIT, inside a transaction you can roll back, or all three.
Dialects differ more than they look
SQL is a standard that no two databases implement identically, and formatters have to make assumptions.
Quoting is the visible difference: double quotes for identifiers in Postgres, backticks in MySQL, square brackets in SQL Server. Then there are dialect-specific constructs - Postgres casting with a double colon, MySQL and Postgres disagreeing about LIMIT and OFFSET syntax, and every engine having its own date functions.
A formatter aiming to be general will handle common SQL well and may lay out unusual dialect syntax awkwardly. If output looks wrong, check whether the construct is standard before assuming the formatter is broken.
When not to reformat
Queries in version control. Reformatting a large query produces a diff touching every line, which buries the change you actually made and makes review harder. If a project has a house style, follow it.
Queries with meaningful comments and spacing. A formatter can move comments away from the lines they describe.
The useful habit is to format queries you are reading and trying to understand, and leave queries you are committing in whatever form the team has agreed.
A cross product hiding on one line
SELECT u.name, o.total FROM users u, orders o WHERE o.status = 'paid' AND u.active = true OR u.role = 'admin' ORDER BY o.total DESC LIMIT 10SELECT u.name,
o.total
FROM users u,
orders o -- no join condition
WHERE o.status = 'paid'
AND u.active = true
OR u.role = 'admin' -- binds as (status AND active) OR role
ORDER BY o.total DESC
LIMIT 10Two serious problems, both invisible on one line. There is no condition linking users to orders, so every user is paired with every order - a thousand users and a thousand orders gives a million rows before filtering. And the OR means an admin matches regardless of order status, which is almost certainly not what was intended. The query runs fine and returns ten rows, which is why nobody notices.
What this tool will not do
- Formatting does not validate. A query can format perfectly and still reference a table that does not exist.
- Select Standard SQL, PostgreSQL, MySQL, or SQLite. Unsupported vendor extensions and stored procedures may fail to format.
- Layout and comment placement may change. Review output, especially comments and database-specific hints.
- There is no query analysis, no execution plan and no performance advice - use your database's own EXPLAIN for that.
- Input is limited to 100,000 characters to keep browser formatting responsive.