Will it change what my query does?

No. Only whitespace and keyword casing change. Identifiers, string literals and the structure of the query are left exactly as written.

Which dialects are supported?

PostgreSQL, MySQL, MariaDB, SQLite, T-SQL, BigQuery, Snowflake and standard SQL, among others. Pick the closest match for the best results.

Is it safe to paste a production query?

Yes. Formatting is done locally, so queries containing table names, schema details or literal values in a WHERE clause never leave your machine.

Developer tools

SQL Formatter

Format SQL queries for readability across several dialects.

DialectKeywordsIndent

SQL input

select u.id, u.name, count(o.id) as order_count from users u left join orders o on o.user_id = u.id where u.created_at >= '2026-01-01' and u.status in ('active','trial') group by u.id, u.name having count(o.id) > 3 order by order_count desc limit 20;

select u.id, u.name, count(o.id) as order_count from users u left join orders o on o.user_id = u.id where u.created_at >= '2026-01-01' and u.status in ('active','trial') group by u.id, u.name having count(o.id) > 3 order by order_count desc limit 20;

Formatted

SELECT
  u.id,
  u.name,
  count(o.id) AS order_count
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
  AND u.status IN ('active', 'trial')
GROUP BY
  u.id,
  u.name
HAVING
  count(o.id) > 3
ORDER BY
  order_count DESC
LIMIT
  20;

SELECT
  u.id,
  u.name,
  count(o.id) AS order_count
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
  AND u.status IN ('active', 'trial')
GROUP BY
  u.id,
  u.name
HAVING
  count(o.id) > 3
ORDER BY
  order_count DESC
LIMIT
  20;

Only whitespace and keyword casing changed — identifiers, literals and query structure are untouched.

About this tool

Turn a single-line query — or one mangled by an ORM log — into something readable, with clauses broken onto their own lines and joins aligned. Several dialects are supported so vendor-specific syntax is not mangled.

How to use it

Paste your query.
Pick the dialect that matches your database.
Choose keyword casing, then copy the formatted result.

Formatting never changes what a query does

Only whitespace and keyword casing change. Identifiers, string literals, comments and the structure of the query are left exactly as written — so a formatted query returns identical results to the original.

That guarantee has one boundary worth knowing: string literals are never touched. If a literal contains newlines or significant spacing, it is preserved byte for byte. The formatter only reflows the SQL around it.

Keyword casing is cosmetic but conventional. Uppercase keywords against lowercase identifiers makes the shape of a query scannable at a glance — you can see the clauses without reading the words. It has no effect on execution; SQL keywords are case-insensitive.

Identifier casing is not cosmetic and is deliberately left alone. In PostgreSQL an unquoted identifier folds to lowercase while a quoted one is case-sensitive, so "User" and user are different tables. Changing that casing would change the query.

Choosing the right dialect

Pick the dialect matching your database and vendor-specific syntax formats correctly instead of confusing the parser.

The differences that actually matter:

Quoting. PostgreSQL and standard SQL use "double quotes" for identifiers; MySQL and MariaDB use backtick quoting; SQL Server uses [brackets].
Parameters. $1 in PostgreSQL, ? in MySQL and SQLite, @name in T-SQL.
Limits. LIMIT 10 almost everywhere, TOP 10 in T-SQL, FETCH FIRST 10 ROWS ONLY in Db2 and standard SQL.
String concatenation. || in standard SQL, CONCAT() in MySQL, + in T-SQL.

If you are unsure, Standard SQL is a reasonable default — it will format common syntax well and simply not recognise vendor extensions, which shows up as slightly odd line breaks rather than anything broken.

Frequently asked questions

Will it change what my query does?: No. Only whitespace and keyword casing change. Identifiers, string literals and the structure of the query are left exactly as written.
Which dialects are supported?: PostgreSQL, MySQL, MariaDB, SQLite, T-SQL, BigQuery, Snowflake and standard SQL, among others. Pick the closest match for the best results.
Is it safe to paste a production query?: Yes. Formatting is done locally, so queries containing table names, schema details or literal values in a WHERE clause never leave your machine.