A SQL formatter that knows your dialect
Queries copied from application logs, ORMs or monitoring tools usually arrive as one long line. This SQL formatter turns them into a readable layout: each clause on its own line, selected columns and conditions indented beneath it, subqueries and CTEs nested, and keywords in consistent case. It is built on the open-source sql-formatter library and supports 20 SQL dialects, because MySQL, PostgreSQL, SQL Server and the others each have syntax the rest do not.
Example
select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.status='active' and o.total>100 group by u.id,u.name having count(o.id)>2 order by orders desc limit 20;
SELECT
u.id,
u.name,
COUNT(o.id) AS orders
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.status = 'active'
AND o.total > 100
GROUP BY
u.id,
u.name
HAVING
COUNT(o.id) > 2
ORDER BY
orders DESC
LIMIT
20;
Every clause starts a new line, each column is on its own line, AND begins a new line inside WHERE, and operators are spaced. Functions such as COUNT are uppercased along with keywords. String literals like 'active' are left as they are. One exception: in the BigQuery, Hive, Spark SQL and Couchbase N1QL dialects a doubled quote inside a string, as in 'it''s', is read as two strings and printed as 'it' 's', so check such literals after formatting.
Why the dialect matters
SQL dialects disagree on quoting, operators and parameters. Choosing the right one lets the formatter tokenize your query correctly:
| Dialect | Syntax it understands |
|---|---|
| MySQL / MariaDB | `backtick` identifiers, @var := value, ? placeholders |
| PostgreSQL | :: casts, ->> JSON operators, $1 parameters, dollar-quoted strings |
| SQL Server (T-SQL) | [bracketed names], TOP, @param |
| BigQuery | `project.dataset.table`, SELECT * EXCEPT (...), STRUCT and ARRAY |
| Oracle PL/SQL | :bind variables and Oracle keywords |
The other dialects are SQLite, Snowflake, Amazon Redshift, IBM Db2 and Db2 for i, Apache Hive, Spark SQL, Trino / Presto, DuckDB, ClickHouse, SingleStoreDB, TiDB and Couchbase N1QL. If a query fails with "Parse error: Unexpected ...", the dialect is the first thing to check. For example, select total::numeric from t fails as Standard SQL but formats as PostgreSQL, and [Order ID] needs the SQL Server dialect.
For formatting conventions and a closer look at how the 20 dialects differ, read How to format SQL.
Options explained
- Keyword case – UPPERCASE (default) is the most common convention because it separates SQL keywords from table and column names at a glance. lowercase is popular in dbt projects and some style guides. Preserve leaves each keyword as typed. The setting also applies to data types and function names. An unquoted column name that is also a keyword in the chosen dialect, such as
keyortype, is upper-cased like a keyword. With the ClickHouse dialect, function and type names keep the case you typed, but such column names (there alsoname) are still upper-cased, so choose Preserve for ClickHouse queries. - Indent – 2, 3, 4 or 8 spaces, or tabs, for clause contents and nested queries.
- Minify – the second button strips comments and collapses the query onto one line, useful for embedding SQL in code or config.
Scripts with several statements are formatted one after another, separated by a blank line, so you can paste an entire migration or seed file.
What gets formatted
SELECT queries with joins, subqueries and WITH common table expressions; CASE expressions (each WHEN on its own line); window functions with OVER (PARTITION BY ...); INSERT, UPDATE and DELETE statements; and DDL such as CREATE TABLE with one column definition per line. Comments are kept.
Common errors and fixes
- Unexpected token after a quote: an unterminated string. SQL escapes a quote inside a string by doubling it:
'it''s'. - Template placeholders like
{{ ref("orders") }}(dbt) or#{id}(MyBatis) are not SQL and may fail to parse. Replace them with a placeholder name before formatting. - Procedural code: long stored procedures with vendor-specific control flow may not format perfectly; format the queries inside them individually.
A formatter does not execute or validate queries against your schema. To turn query results into other formats, see SQL to JSON, and to prepare text for a SQL string literal, SQL Escape. For compact output only, the SQL Minifier keeps optimizer hints. Your queries are formatted in the browser and never sent to a server.