SQL Formatter – Beautify SQL Online

Before and after

Input

select o.id,c.name,sum(i.qty*i.price) total from orders o join customers c on c.id=o.customer_id join order_items i on i.order_id=o.id where o.status='paid' group by o.id,c.name order by total desc

Standard layout

SELECT
  o.id,
  c.name,
  SUM(i.qty * i.price) total
FROM
  orders o
  JOIN customers c ON c.id = o.customer_id
  JOIN order_items i ON i.order_id = o.id
WHERE
  o.status = 'paid'
GROUP BY
  o.id,
  c.name
ORDER BY
  total DESC

The Aligned layout lines up everything after the keywords, which some teams find easier to scan in long reports:

Aligned layout

SELECT    o.id,
          c.name,
          SUM(i.qty * i.price) total
FROM      orders o
JOIN      customers c ON c.id = o.customer_id
JOIN      order_items i ON i.order_id = o.id
WHERE     o.status = 'paid'
GROUP BY  o.id,
          c.name
ORDER BY  total DESC

Formatting conventions

One clause per line: SELECT, FROM, WHERE, GROUP BY, ORDER BY each start a new line.
One column per line in the SELECT list, so adding or removing a column is a one-line diff.
Joins indented under FROM, with their ON condition on the same line.
AND / OR at the start of a line, so conditions can be commented out individually.
Subqueries and CTEs indented one level, so nesting is visible at a glance.

Quoting identifiers by database

Quoting is the most common reason a query won’t parse in the wrong dialect. Identifiers that are reserved words, like a column named order, must be quoted:

Database	Identifier	String
PostgreSQL, SQLite, Oracle, standard SQL	`"order"`	`'text'`
MySQL, MariaDB	`order`	`'text'`
SQL Server	`[order]`	`'text' or N'text'`
BigQuery	`project.dataset.table`	`'text' or "text"`

One-line mode

One line collapses a query for a log message, a shell command or a string in code. Line comments would comment out the rest of the line, so they are turned into block comments:

Multi-line

SELECT id,
       name -- display name
FROM users
WHERE active = 1;

One line

SELECT id, name /* display name */ FROM users WHERE active = 1;

Format SQL in your editor and CI

# sql-formatter CLI (the library this tool uses)
npx sql-formatter --language postgresql query.sql

# SQLFluff: formatter and linter with dialect support
pip install sqlfluff
sqlfluff fix --dialect postgres models/

# pgFormatter for PostgreSQL
pg_format -i query.sql

Comparing two versions of a query? Paste them into the Diff Checker after formatting both the same way, so only real changes show up.

Frequently asked questions

How do I format a SQL query?

Paste the query into the formatter above and pick your database dialect. It is formatted as you type: each clause starts on its own line, columns and conditions are indented, and keywords are uppercased. Copy or download the result as a .sql file.

Why does the dialect matter?

Databases differ in syntax the formatter must understand: MySQL quotes names with backticks, SQL Server with [brackets], PostgreSQL has :: casts and $1 parameters, BigQuery has backtick-quoted table paths. With the wrong dialect, a query may fail to parse. The tool then checks other dialects and suggests one that works.

Does formatting change what my query does?

No. Only whitespace and the case of keywords change; table names, column names, string literals and comments are kept exactly. Keyword case is safe because SQL keywords are case-insensitive. If you use case-sensitive quoted identifiers, they are not touched.

Should SQL keywords be uppercase?

It is a convention, not a rule. Uppercase keywords (SELECT, FROM, WHERE) make them stand out from table and column names, which is why most style guides and this tool default to it. Many teams prefer lowercase for less visual noise; choose lower or Keep to match your codebase.

Is my SQL sent to a server?

No. The formatter runs in your browser, so queries containing table names, customer data or credentials never leave your machine. That makes it safe for production queries copied from logs or monitoring tools.