About the SQL Formatter
This SQL formatter takes a query written on a single line — typically one copied out of an application log, an ORM debug statement or a colleague's chat message — and lays it out clause by clause. Major keywords such as SELECT, FROM, WHERE, GROUP BY, ORDER BY and every JOIN variant start a new line, AND and OR conditions are indented beneath the clause they belong to, and items in a select list are placed one per line. You choose whether keywords are uppercased or lowercased. Since SQL keywords are case-insensitive and only whitespace changes, the reformatted query executes exactly as before. Everything runs locally, so queries referencing internal schema names stay private.
How to use the SQL Formatter
- 1
Paste your query into the 'SQL query' box.
- 2
Set 'Keyword case' to UPPERCASE or lowercase depending on your team's house style.
- 3
Read the formatted output, where each major clause begins a new line and conditions are indented under it.
- 4
Copy the query or download it as query.sql to commit alongside a migration or a report definition.
What people use it for
Reviewing a query from a slow query log
Logged SQL arrives as one unbroken line. Formatting it makes the join order and the filter conditions legible so you can reason about what the planner is doing.
Reading ORM-generated SQL
Query builders emit correct but unreadable statements. Laying one out shows whether an innocent-looking relation actually produced five joins behind your back.
Preparing SQL for a pull request
A migration or reporting query formatted one clause per line produces line-level diffs, so a reviewer sees which condition changed rather than a rewritten single line.
Why keywords are uppercased and identifiers are not
Uppercasing keywords is the oldest convention in SQL style and it survives for a practical reason: SQL has no sigils separating language from data, so a query whose columns are named after keywords is perfectly legal and thoroughly confusing. Casing the keywords gives the eye an instant split between the grammar of the query and the names of your tables and columns. The convention is safe because the SQL standard requires keywords to be case-insensitive, so select and SELECT are the same token to every engine. Identifiers are a different matter, and this formatter never touches them. PostgreSQL folds unquoted identifiers to lowercase and treats a quoted mixed-case name as distinct from the unquoted one. MySQL table name case sensitivity depends on the lower_case_table_names setting and the underlying filesystem, so a query that works on macOS can fail on Linux. SQL Server follows the database collation. Recasing identifiers automatically would risk breaking working queries.
What a formatter can and cannot tell you about a query
Formatting is presentation, not analysis. It will not tell you that a LEFT JOIN followed by a WHERE condition on the right-hand table has quietly become an inner join, that a function wrapped around an indexed column prevents that index being used, or that a correlated subquery is running once per row. For that you need EXPLAIN, or EXPLAIN ANALYZE in PostgreSQL and MySQL 8, which shows the planner's chosen access paths and its cost estimates against the real ones. What formatting does buy you is the ability to spot such problems by eye: once each join sits on its own line, an accidental cross join from a missing ON clause is obvious, and once the WHERE conditions are stacked, a filter referencing the wrong table alias stands out immediately. Treat readable SQL as the precondition for a useful review rather than a substitute for measuring the query.
Tips
- Keyword matching is word-boundary based, so a column literally named order or count may be recased — quote such identifiers in the source.
- Format before committing rather than afterwards, so the diff in your pull request is the one your reviewer reads.
- Very long IN lists stay long; consider joining against a temporary table or a VALUES list instead.