How the SQL formatter works
The page uses the open-source sql-formatter library (version 15.6.9), loaded into your browser. When you click Format, the library tokenizes your SQL using the grammar of the dialect you picked, parses it into clauses, and prints it back with a consistent layout:
- each main clause (
SELECT, FROM, WHERE, GROUP BY, ORDER BY, LIMIT) starts on its own line
- the items inside a clause are indented by 2 spaces, one column or condition per line
AND and OR start new lines inside WHERE and HAVING- several statements separated by
; are split with a blank line between them
- comments are kept, and keyword case is left exactly as you wrote it
The dialect list covers Standard SQL, MySQL, PostgreSQL, SQLite, T-SQL (Microsoft SQL Server), and PL/SQL (Oracle). Nothing is run against a database: the formatter only rearranges text.
Example: a report query copied from application logs
ORMs and query builders usually log SQL as one long line:
SELECT u.id, u.email, COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at >= '2026-01-01' AND o.status IN ('paid','shipped') GROUP BY u.id, u.email HAVING COUNT(o.id) > 3 ORDER BY orders DESC LIMIT 20;
Formatted with the MySQL dialect:
SELECT
u.id,
u.email,
COUNT(o.id) AS orders
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.created_at >= '2026-01-01'
AND o.status IN ('paid', 'shipped')
GROUP BY
u.id,
u.email
HAVING
COUNT(o.id) > 3
ORDER BY
orders DESC
LIMIT
20;
In this layout a logic problem stands out: the WHERE clause filters on o.status, a column of the left-joined table. That quietly turns the LEFT JOIN into an inner join, because users with no orders have NULL there and are filtered out. If you meant to keep them, move the condition into the ON clause. Reformatting is often the fastest way to see this kind of mistake.
Common problems and how to fix them
Operators split apart by the wrong dialect
Formatted as Standard SQL, the PostgreSQL expression data->>'email' comes out as data - > > 'email', which no longer runs. Standard SQL does not know the ->> JSON operator, so it treats each symbol separately. Select PostgreSQL and the operator is kept intact, along with :: casts such as id::text.
Parse error on unbalanced parentheses
A query like SELECT * FROM t WHERE (a = 1 stops with Parse error at token: «EOF» at line 1 column 29. EOF means the formatter reached the end of the text while still inside the open parenthesis. The line and column point to where it gave up, which is often after the real mistake.
Quoted identifiers
MySQL backticks (`order`) and T-SQL brackets ([Order Date]) are recognized as single identifiers, so reserved words and names with spaces are not broken up. Choose the matching dialect so the formatter knows which quoting style to expect.
Comments before a comma
A line comment at the end of a column, followed by a leading comma on the next line, can leave the comma on a line of its own. The query still runs. Put the comma before the comment if you want a tidy result.
What the formatter does not do
- No validation against your schema. Misspelled table or column names are formatted without complaint.
- No case conversion. Keywords keep their original case.
- No execution or optimization. It does not run, explain, or rewrite queries.
- Fixed layout. Output always uses 2-space indentation in the style shown above.
When to use a different tool
- To compress a query to one line for a config file or a JSON payload, use the SQL Minifier.
- To write the PHP that runs the query, for example a PDO prepared statement, open the PHP Editor.
- To read query results exported as JSON, use the JSON Formatter.
Frequently asked questions
Which dialect should I choose?
Choose the database the query will run on: MySQL, PostgreSQL, SQLite, T-SQL for Microsoft SQL Server, or PL/SQL for Oracle. Standard SQL works for simple portable queries, but it does not know vendor operators such as the PostgreSQL ->> JSON operator or :: casts.
Why do I get a parse error for a query that runs fine in my database?
The formatter has its own grammar for each dialect. If the dialect is wrong, or the query uses syntax the library does not cover, it stops with a message such as "Parse error at token ... at line 1 column 29". Switch to the matching dialect first. Unbalanced parentheses also cause this error.
Does the formatter convert keywords to uppercase?
No. Keyword case is kept exactly as you typed it: select stays select and SELECT stays SELECT. Only line breaks and indentation change.
Can formatting change what my query does?
With the correct dialect, only whitespace changes. With the wrong dialect, an operator the formatter does not recognize can be split into separate symbols, for example ->> becoming - > >, which breaks the query. Compare the output with the input if you are unsure.
Is my SQL sent to a server?
No. Formatting runs in your browser with the sql-formatter library, and nothing is executed against a database. The editor keeps a copy in your browser local storage so it survives a reload.