SQL Query Formatter
SQL generated by an ORM or pasted out of a log arrives as one enormous line, and reading a five-way join in that state is genuinely difficult. Formatting is not cosmetic here: consistent structure is what makes a bad join condition visible.
How to use it
- Paste a query into the input.
- Keywords are uppercased and clauses are placed on their own lines.
- Copy the formatted query. Nothing is transmitted, which matters for queries containing real values.
Why keyword casing is the convention it is
SQL is case-insensitive for keywords, so SELECT and select behave identically. The convention of uppercasing keywords predates syntax highlighting: on a monochrome terminal, capitalisation was the only way to distinguish language structure from table and column names at a glance.
It survives because it still works. In a log file, a code review diff, or a database console without highlighting, uppercase keywords let you find the clause boundaries without reading the whole statement.
Identifiers are a different matter. Whether table and column names are case-sensitive depends on the database and, on MySQL, on the operating system underneath it. Formatting leaves identifier casing exactly as written, because changing it can break the query.
What formatting makes visible
Putting each JOIN and its ON condition on its own line exposes the most expensive mistake in SQL: a join with no condition, or one whose condition does not actually constrain the relationship. On one line among two hundred other characters, a missing ON clause is invisible. On its own line, the gap is obvious.
Aligned WHERE predicates make operator precedence visible too. A mixture of AND and OR without parentheses parses according to precedence rules rather than the author intent, and the formatted layout is where that becomes apparent.
Formatting also makes diffs meaningful. A query held on one line produces a single-line change for any edit, and the review shows nothing useful. Broken across clauses, the diff shows what actually changed.
What this cannot do
It is a formatter, not a parser with a semantic model. It does not validate that the query is syntactically correct, that the tables exist, or that the columns are spelled right. Malformed SQL will be formatted as malformed SQL.
It also does not analyse performance. Reformatting changes nothing the query planner sees, and identifying a missing index or a scan that should be a seek requires EXPLAIN against the actual database with its actual statistics.
Dialect coverage is broad rather than exhaustive. Standard clauses and the common vendor extensions format correctly; unusual constructs such as PostgreSQL dollar-quoted function bodies or T-SQL procedural blocks are passed through rather than restructured.
A note on queries with values in them
Queries pulled from application logs frequently contain real data inlined into the statement: customer email addresses, order totals, internal identifiers. Pasting one of those into a server-side formatter sends that data to a third party.
Formatting here happens in the page, so the query is never transmitted. That is the main reason to prefer a client-side formatter for anything that came out of a production log.
At a glance
| Keyword casing | Uppercased |
|---|---|
| Identifier casing | Left exactly as written |
| Validation | None, formatting only |
| Transmitted | Nothing |
Frequently asked questions
Does formatting change what the query does?
No. Only whitespace and keyword capitalisation change, and SQL keywords are case-insensitive. Identifiers are left untouched precisely because their case can matter.
Will this tell me if my query is valid?
No. It is a formatter, not a parser with a semantic model. Invalid SQL is formatted as invalid SQL. Run it against the database to validate.
Which SQL dialects work?
Standard clauses and common vendor extensions across MySQL, PostgreSQL, SQL Server, and SQLite. Procedural blocks and dollar-quoted bodies are passed through rather than restructured.
Can it help me optimise a slow query?
Only indirectly, by making the structure readable enough to spot problems like an unconstrained join. Actual optimisation needs EXPLAIN output from your database.
Read more
Formatting and encoding — Pretty-printing catches bugs, Base64 costs 33 percent, and escaping applied in the wrong context prevents nothing.