SQL formatter — beautify queries for 17 SQL dialects

Paste a query and the formatter puts each clause on its own line, indents the columns and conditions, and sets keyword case, for any of 17 SQL dialects.

Live demo · real result from this tool
Keywords
Indent
AND / OR

Formatted SQL

SELECT  u.id,  u.name,  count(o.id) AS ordersFROM  users u  LEFT JOIN orders o ON o.user_id = u.idWHERE  u.active = 1  AND o.created_at >= '2025-01-01'GROUP BY  u.id,  u.nameHAVING  count(o.id) > 2ORDER BY  orders DESCLIMIT  10;

Processed on your device — nothing is uploaded.

How to use the SQL formatter

  1. Paste your query into the Input box.
  2. Choose the Dialect that matches your database, for example PostgreSQL or SQL Server (T-SQL).
  3. Choose how Keywords are written: UPPER, lower or As written.
  4. Pick an Indent of 2 spaces, 4 spaces or a tab, and whether AND / OR go at the start or end of a line.
  5. Copy the Formatted SQL, or download it as query.sql.

What it does and when to use it

SQL often reaches you as one long line: copied from an application log, generated by an ORM, or written in a hurry. The formatter makes it readable by placing SELECT, FROM, JOIN, WHERE, GROUP BY and ORDER BY on their own lines, listing columns one per line, and lining up conditions. Readable SQL makes code review easier and helps you spot a wrong join or a missing condition before it reaches production.

Supported dialects are Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark SQL, Trino/Presto, IBM Db2, Hive, Couchbase N1QL, SingleStore and TiDB.

If you need the opposite, the SQL minifier squeezes a query onto one line. For config and data files, the XML formatter and the JSON formatter work the same way.

How it works

The tool uses the open-source sql-formatter library, which loads in your browser the first time you use the page. It splits the query into tokens using the rules of your chosen dialect, so it knows, for example, that [Orders] is a quoted name in SQL Server. It then rebuilds the query with standard line breaks and indentation. String literals and comments are kept as they are.

Worked examples

All output below is produced by the formatter with default settings unless noted.

A join with conditions. The one-liner select u.name, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.active = 1 and o.total > 10 group by u.name order by orders desc becomes:

SELECT
  u.name,
  count(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.active = 1
  AND o.total > 10
GROUP BY
  u.name
ORDER BY
  orders DESC

Keywords become upper case, but the function name count is left as written.

SQL Server with lower-case keywords. SELECT TOP 5 * FROM [Orders] WHERE [Total] > 10, dialect T-SQL, Keywords lower, gives select, top 5 *, then from with [Orders] on the next line. The square-bracket names are understood and kept.

Limits and tips

  • Long stored procedures with heavy dialect-specific syntax may come out with odd indentation. Read through the result before committing it.
  • Comments are kept in the output; check that each one still sits next to the line it describes.
  • Formatting is not validation. A query can format cleanly and still fail because a table or column does not exist.
  • Team style guides vary. Pick the options that match yours and keep them the same across files.

Frequently asked questions

Does formatting change what my query does?
No. The formatter changes only line breaks, indentation and, if you choose, the case of keywords. Table names, column names, values and the logic stay exactly as written.
Which SQL dialect should I choose?
Pick the database you run the query on. Dialects differ in how they quote names (backticks in MySQL, square brackets in SQL Server, double quotes in PostgreSQL), and in special syntax such as TOP, LIMIT or PL/SQL blocks. Standard SQL works for simple queries.
Why do I get an error instead of formatted SQL?
The formatter has to understand the query's tokens. An unclosed string, a stray bracket or syntax from a different dialect can stop it. Check the dialect setting first, then look near the position the message mentions.
Is it safe to paste production queries?
The query is formatted in your browser and is not uploaded. It is still good practice to remove passwords or personal data before sharing a query anywhere.
Can it make my query faster?
No. Layout has no effect on speed. To speed up a query, look at its execution plan in your database (for example EXPLAIN) and at indexes.

Written by the ToolsRift team · Last updated

Pages are drafted with AI assistance and checked by automated tests. How we write and check pages.

Was this tool useful?

Report a problem

Start typing to search every tool.

↑ ↓ to moveEnter to openEsc to close