SQL Formatter
Paste a query and get it back readable, with every clause on its own line.
What is a SQL formatter?
A SQL formatter rewrites a query with each clause on its own line and the keywords in a consistent case, so a long statement can be read. It does not run the query, check it against a database or change what it returns: it only moves the whitespace.
How it works
The formatter puts each clause, SELECT, FROM, WHERE, GROUP BY, on its own line, indents what belongs to it, breaks the select list at the commas and indents a subquery past the clause that contains it.
Keywords are cased consistently, upper by default, while identifiers keep whatever case you wrote: a column called createdAt stays createdAt, because in a case-sensitive database changing it would change the query.
Strings, quoted identifiers and comments are set aside before the keyword pass and put back after it, so the word "from" inside a string literal is never mistaken for a FROM clause.
What is an SQL formatter
An SQL formatter rewrites a query's whitespace and capitalisation so its structure is visible, without changing what the query does. Keywords go on their own lines, the columns of a SELECT line up, nested conditions are indented to the depth they actually sit at. The text changes; the result set does not.
It is a readability tool rather than a correctness one. A formatter will happily lay out a query that returns the wrong rows, and laying it out is often how you see that it does: a JOIN condition that was hiding at the end of a 400 character line becomes an indented clause you can read.
Why a formatter and not a parser
SQL has no single grammar. The core is standardised, and then every database adds to it: Postgres has arrays and JSONB operators, MySQL has backticks, SQL Server has square brackets and TOP, BigQuery has its own date functions and a different quoting rule. A formatter that fully parses has to pick a dialect, and then mangles the others.
So this one works by keyword. It knows which words start a clause and lays the query out around them, and it knows how to protect the parts where keywords are not keywords. That makes it dialect-agnostic: it will format a Postgres query, a MySQL query and a stored-procedure body without being told which it is, at the cost of not reformatting the inside of expressions it does not understand. For reading a query that arrived as one line, that is the right trade.
What it does to your query
- Clauses on their own lines SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, the JOIN family and ON. This is the change that makes a query skimmable: the shape of the statement becomes visible before you read any of it.
- The select list broken at commas one column per line, so adding or removing one is a one-line diff rather than a changed line of 300 characters.
- Subqueries indented a query inside brackets sits one level deeper, so the nesting is visible rather than inferred.
- Keywords cased, identifiers untouched upper-case keywords are the common convention and make the structure stand out against the names. Your table and column names are left exactly as written, which matters in any database where case is significant.
- Idempotence formatting an already-formatted query gives the same result, so running it twice is safe and a formatted file stays stable in version control.
What it deliberately does not do
It does not validate. A query with a typo in a column name formats perfectly well, because only your database knows what columns exist. It does not optimise, rewrite, or tell you that a subquery would be faster as a join. And it does not execute anything: there is no connection, no credentials and nowhere for a query to run.
It also leaves the inside of complex expressions alone. A long CASE statement or a window function is kept on its line rather than exploded, because breaking an expression correctly needs the grammar this tool deliberately does not have, and a wrong break is worse than no break.
Formatting before a code review
The practical reason to format is the diff. A query written as one long line changes as one long line: a reviewer sees that something changed and has to read 300 characters to find out what. Formatted, the same change is one line added and one removed, and the review takes a second.
That argues for formatting queries before they go into version control rather than only when reading them. Pick one convention, upper-case keywords, two spaces, one column per line is the common one, and apply it to everything, so a diff never contains a reformat mixed with a change. If your team runs a linter such as sqlfluff in CI, match its settings here and the two will agree.
Pasting a query that touches real data
A query is not neutral text. It carries table names, column names and often literal values from production: an email address in a WHERE clause, an internal id, the shape of a schema you would not publish. Pasting one into a site that posts to a backend hands over all of that.
This runs in the page. Nothing is sent anywhere, the tool works with the network disconnected, and you can check that in the network tab. For a formatter, a tool you reach for precisely when you are debugging something real, that is not a nicety.
Questions people ask
Which SQL dialect does it support?
All of them, loosely. It formats by keyword rather than by parsing, so Postgres, MySQL, SQL Server, SQLite and BigQuery queries all lay out correctly without being told which they are.
Will it change my column names?
No. Only keywords are re-cased. Identifiers keep exactly the case you wrote, because in a case-sensitive database changing them would change the query.
Is my query sent anywhere?
No. The formatting runs in your browser and nothing is uploaded, so a query carrying production table names and literal values stays on your machine.
Does it check my SQL for errors?
No. Only your database knows which tables and columns exist. A query with a typo formats perfectly well.
Why is my long CASE statement still on one line?
Breaking an expression correctly needs a full grammar, which a dialect-agnostic formatter deliberately does not have. A wrong break would be worse than none, so expressions are left as written.