SQL Formatter
Paste a one-line query and get it laid out clause by clause.
The answer appears here as you type.
Guide: From one long line to a query you can read2 min read
From one long line to a query you can read
A query copied from a log, an ORM or a monitoring tool arrives on a single line, three hundred characters long. Paste it here and it comes out with one clause per line — SELECT, FROM, JOIN, WHERE, GROUP BY — the columns stacked and the WHERE conditions split on AND and OR. It is the fastest way to spot the missing JOIN or the condition that filters too much.
Keywords can be upper case, lower case or left as typed; indentation is 2 or 4 spaces. Table names, quoted strings and numbers are never touched: the formatted query does exactly what the original did. Comments (-- and /* */) stay where they were.
Pick your database's dialect
Every database has its quirks. MySQL and MariaDB quote names with backticks, SQL Server uses brackets and TOP, PostgreSQL has :: for casts, $1 for parameters and double quotes for identifiers, Oracle has PL/SQL blocks, and BigQuery accepts hyphenated names in backticks. With the right dialect those are understood; with the wrong one they can turn into an error. When in doubt, standard SQL works for simple queries.
When reading fails, the message gives the line and the text where it stopped. It is almost always an open quote, an unmatched bracket or syntax from another database.
Nothing is uploaded
A query reveals the database schema and often real data in the WHERE clause: emails, account numbers, order IDs. Formatting happens in this tab and nothing leaves your computer. To compare a query before and after a change, use text compare; to read the JSON it returned, the JSON formatter.
Frequently asked questions
Does the formatter change what the query does?
No. It only changes whitespace, line breaks and, if you ask, the case of keywords such as SELECT and JOIN. Table names, column names, strings and numbers are left exactly as they were. Running the formatted query gives the same result.
Why does the dialect matter?
Because the same characters mean different things. MySQL quotes names with backticks, SQL Server with [brackets], PostgreSQL uses :: for casts and $1 for parameters, Oracle has its own PL/SQL blocks. With the wrong dialect some of that is read as an error or split in the wrong place.
It says it could not read my query. What is wrong?
Usually an unclosed quote or bracket, or syntax from another database. The line in the message is where reading stopped. Check the quotes near it, then try the dialect of the database the query was written for.
Are comments kept?
Yes. Line comments (--) and block comments (/* */) stay where they were, attached to the clause they sit next to.
Is my query sent to a server?
No. Formatting runs in this tab, so table names, customer data in WHERE clauses and internal schema never leave your computer. The page works offline once it has loaded.