How to use it
Start with “Dialect” and choose the database the query will run on. The choices are “Standard SQL”, “MySQL”, “PostgreSQL”, “SQLite”, “T-SQL (SQL Server)”, and “BigQuery”. Then put your query in “Input” and set three things below it.
- Keyword case: “Upper (SELECT)”, “Lower (select)”, or “Keep as typed”.
- Indent: “2 spaces”, “4 spaces”, or “Tab”.
- Blank lines between queries: how many blank lines go between queries separated by a semicolon (;). It takes 0 through 5 and starts at 1.
Here is the one-liner below formatted with Standard SQL, upper case, and 2 spaces.
select u.id, 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' group by u.id having count(o.id) > 3 order by orders desc
SELECT
u.id,
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'
GROUP BY
u.id
HAVING
count(o.id) > 3
ORDER BY
orders DESC
In “Output”, keywords are bold, strings and numbers are colored, and comments are in italics. That highlighting goes purely by what a word looks like, so a column whose name matches a reserved word, such as default or index, shows up bold like a keyword unless you quote it. When the result is longer than 200,000 characters, you see “The result is large, so it is shown without highlighting” and the text is shown plain. “Lines” and “Size” under the result measure the formatted result.
If you paste several queries at once, each one is formatted separately, split at the semicolons. When the last query has no semicolon, the result doesn’t add one.
What Keyword case does and doesn’t change
“Keyword case” applies only to reserved words such as select, from, as, and join. Function names, data types, table and column names, and the text inside strings are left as you typed them.
- Format
select count(*), cast(x as int) from twith “Upper (SELECT)” and onlySELECT,AS, andFROMbecome upper case, whilecount(*)andintstay lower case. - Format
SELECT Now() FROM twith “Lower (select)” andselectandfrombecome lower case, whileNow()stays the same. - The text inside the quotes in
where name = 'select from'doesn’t change under any setting.
If your team’s style also upper-cases COUNT and INT, you’ll have to fix those by hand.
What happens when you pick the wrong dialect
Databases disagree on how quotes and placeholders are written. Choose a dialect that doesn’t match, and a query that runs fine on your database can’t be parsed and comes back as an error. The table shows the same inputs run through each of the six dialects.
| Input | Dialects that give an error | Dialects that format it |
|---|---|---|
select [a] from [t] |
Standard SQL, MySQL (line 1, column 8) | PostgreSQL, SQLite, T-SQL, BigQuery |
select `a` from `t` |
PostgreSQL, T-SQL (line 1, column 8) | Standard SQL, MySQL, SQLite, BigQuery |
select a::int from t |
Standard SQL, MySQL, SQLite, BigQuery (line 1, column 9) | PostgreSQL, T-SQL |
select * from t where a = $1 |
Standard SQL, SQLite, T-SQL, BigQuery (line 1, column 27) | MySQL, PostgreSQL |
Even without an error, the result can differ in small ways. Format select top 5 a from t with “T-SQL (SQL Server)” and TOP is upper-cased, but the other five dialects don’t recognize top as a keyword and leave it lower case. Conversely, limit 5 stays lower case only in T-SQL. Choosing the database you actually use is safer than cycling through dialects until the error goes away.
No error doesn’t mean the SQL is correct
The tool doesn’t run your query, and it doesn’t check the grammar all the way through. It splits the text into words, finds where each clause begins, and lines things up, so most broken queries pass straight through.
selct * form users(typos) comes out with no error, still on a single line. The only clue is that it wasn’t split into clauses.select * from users where(the condition is missing) is formatted as usual and simply stops atWHERE.
What does get caught is mostly unbalanced parentheses or quotes, and symbols the chosen dialect doesn’t have. In those cases you see a message such as “This SQL couldn’t be parsed. Check around line 1, column 24.” with that line and a ^ marker.
| Input (Standard SQL) | Position shown | Cause |
|---|---|---|
select * from (select 1 |
line 1, column 24 (end of the input) | parenthesis never closed |
select * from users) |
line 1, column 20 | closed without an opening parenthesis |
select 'abc |
line 1, column 8 | quote never closed |
An unclosed parenthesis points to the end of the input, so look for the unmatched opening parenthesis earlier in the query, not at the marked spot.
The formatting engine is downloaded on first input
Formatting is done by sql-formatter, an open-source library. It’s large, so it’s downloaded the moment you first type a query, not when the page opens, and the result area shows “Formatting…” while that happens. Only the engine code is downloaded, and your query isn’t part of that request. If you open the page, lose your internet connection, and then type for the first time, you see “Couldn’t load the formatting engine. Check your internet connection and reload the page.”
There is no minify option that joins a query onto one line. The library only offers line-by-line formatting, and stripping whitespace directly risks touching the spaces inside strings and comments, so it was left out. If you want fewer lines, setting “Blank lines between queries” to 0 is as far as it goes.
