Lay out a query to be read, without rewriting what is in quotes.
What it's for
Lay out a long database query so a person can read it — each clause on its own line, the conditions indented under WHERE — and make the keywords one consistent case.
Before you start
Have the query to hand, copied from your code, a log or a database tool. It is formatted in your browser and nothing is sent anywhere, which matters when a query names your own tables or holds real values.
Paste the query
Replace the sample in Query with your own SQL. It can be one long line, or several statements separated by semicolons.
Choose how keywords look
Keywords are SQL's own words, such as SELECT, FROM and WHERE. In Keywords, pick UPPER CASE to make them stand out from your names, lower case if your team writes it that way, or Leave as written to change only the layout.
Choose the indent
Indent sets how far lines are pushed in — the AND and OR lines under WHERE, and a query inside brackets: Two spaces, Four spaces or Tab. Match the rest of your code.
Format and copy
Press Format. The tidied query is in the band at the top of the card — it also changes as you type — and Copy puts it on your clipboard.
Reading the result
If it goes wrong
What is inside quotes is not code, and that is the whole difficulty. A formatter that uppercases keywords with a plain search turns a note reading 'select one from the list' into 'SELECT one FROM the list' — silently changing data inside a query you asked only to tidy.
So it tokenises first, and only a keyword is ever recased. Comments are treated the same way.
Column names are not touched either. In PostgreSQL an unquoted identifier folds to lower case and a quoted one does not — so recasing one can change which column a query means.
And it does not parse or validate. It lays a statement out to be read. A formatter claiming to validate SQL would be claiming to implement a dialect.
No, and that is the main thing this tool gets right. A formatter that uppercases keywords with a plain search turns a note reading “select one from the list” into SQL-looking nonsense — silently changing data inside a query you asked only to tidy. This tokenises first, so only something identified as a keyword is ever recased. Comments are left alone for the same reason.
Because case can be meaningful. In PostgreSQL an unquoted identifier folds to lower case while a quoted one does not, so "Order" and Order are different columns — recasing one can change which column a query means. Only keywords are touched.
Yes. Double quotes are the standard identifier delimiter, backticks are MySQL and square brackets are SQL Server, and all three are kept exactly as written. That is what makes a column called order work, and getting it wrong is how a formatter mangles a perfectly valid query.
No. It lays a statement out so a person can read it, which is what you need when staring at a 400-character line from an ORM. It does not parse, validate or rewrite — a formatter claiming to validate SQL would be claiming to implement a dialect, and there are several that disagree.
It gets formatted anyway. Somebody with a query that will not run still wants to see its shape, and refusing to lay it out removes the one thing that might show them where it went wrong.
No. Everything happens in your browser and nothing is transmitted or stored — which matters here, because a query often carries table names, column names and sometimes real values from your own database.
All three are kept as written. That is what makes a column called order work.
Important
Runs entirely in your browser; nothing is transmitted. This lays a query out to be read — it does not parse, validate or rewrite it. Only keywords are recased; identifiers and anything inside quotes are left exactly as written. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
