SQL formatter

How to use it

1. Choose the database dialect. Databases differ in syntax and the formatter needs the right one to recognise each dialect's own constructs. If unsure, use Standard SQL.
2. Choose upper case, lower case or unchanged keywords, and the indent width.
3. Paste SQL on the left and the formatted version appears on the right. Several statements separated by semicolons are fine; the result has a blank line between them.
4. Copy the result. If it cannot be parsed, check for unbalanced brackets or quotes near the reported line and column, or try another dialect.

What formatting does and does not change

Whitespace and keywords only

Formatting is done by the open-source sql-formatter library, which splits the SQL into tokens — keywords, identifiers, strings, comments — and lays them out again clause by clause. SELECT, FROM, WHERE and GROUP BY each start a line, columns, conditions and sort keys are indented one per line, joins sit under the table they extend, and operators get spaces around them. String contents are never touched, so a string like 'a b -- not a comment' stays exactly as it is, and real comments stay where they were.

Keyword case leaves names alone

The keyword option changes reserved words such as SELECT and FROM only; table, column and other identifiers keep the case you wrote. That matters: according to the PostgreSQL documentation, unquoted identifiers are folded to lower case while double-quoted identifiers are case-sensitive, so FOO, foo and "foo" are the same name but "Foo" is a different one. A formatter that changed identifier case could make a quoted name point at a different object.

Why the dialect matters

Each database has its own syntax, such as a backtick-quoted order in MySQL, the $1 parameter and ::int cast in PostgreSQL, or a bracket-quoted [order] in SQL Server. With the right dialect these tokens are kept intact; with the wrong one they may be split, padded with spaces or fail to parse. The sql-formatter documentation lists the dialects it supports; this tool offers the most common dozen or so.

Your SQL stays local

SQL often contains real schemas, customer data or even connection details. Formatting happens entirely in your browser and nothing is uploaded. If you also need to share it with an AI assistant or a colleague, run it through the redaction tool on this site first to replace emails, phone numbers and keys with placeholders.

Examples

Input:

select a.id, count(*) as n from users a left join orders o on o.user_id=a.id where a.created_at>='2026-01-01' and o.status in ('paid','shipped') group by a.id having count(*)>2 order by n desc limit 10;

With MySQL, upper-case keywords and a 2-space indent:

SELECT
  a.id,
  count(*) AS n
FROM
  users a
  LEFT JOIN orders o ON o.user_id = a.id
WHERE
  a.created_at >= '2026-01-01'
  AND o.status IN ('paid', 'shipped')
GROUP BY
  a.id
HAVING
  count(*) > 2
ORDER BY
  n DESC
LIMIT
  10;

With the PostgreSQL dialect, $1::int in SELECT $1::int FROM t is kept as one piece, with no spaces inserted around the ::.

Limits

• As its documentation states, sql-formatter does not support stored procedures or changing the statement delimiter from the semicolon (such as DELIMITER // in the MySQL client).
• Formatting checks that the SQL can be tokenised and that brackets balance, not that it makes sense: missing tables, misspelt columns and syntax your database rejects are not detected.
• Only layout changes. Queries are not optimised and execution plans are unaffected.
• Very long SQL (several MB) can take a few seconds on a phone.

Sources and further reading

• sql-formatter (GitHub)
• PostgreSQL documentation: Lexical Structure (identifiers and quoting)