SQL Formatter

How to use the SQL formatter

1. Paste one or more SQL statements into the input box.
2. Select the dialect that matches your database: standard SQL, MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, MariaDB, BigQuery, Snowflake or Oracle PL/SQL.
3. Choose the keyword case: UPPER, lower, or preserve as written.
4. Set the indent size.
5. Click Format and copy the result.

Your queries are formatted in the browser and are never uploaded or stored, so it is safe to paste production queries that reveal table names or business logic.

Why format SQL?

SQL is whitespace-insensitive: the database runs a one-line query exactly the same as a neatly indented one. People, however, read them very differently. Queries copied from ORM logs, monitoring tools or slow-query reports usually arrive as a single long line, which makes it hard to see which conditions belong to which join or subquery.

A formatter puts each major clause (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) on its own line and indents nested parts consistently. Compare:

select u.id,u.email,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.created_at>='2026-01-01' group by u.id,u.email having count(o.id)>5 order by orders desc;

SELECT
  u.id,
  u.email,
  COUNT(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.email
HAVING
  COUNT(o.id) > 5
ORDER BY
  orders DESC;

The formatted version is easier to review in a pull request, easier to debug, and produces cleaner diffs when someone later adds a column or condition.

Why the dialect matters

Every database extends standard SQL with its own syntax. Choosing the right dialect helps the formatter recognise keywords, operators and identifier quoting correctly:

If a query formats strangely, for example an operator is split or a keyword is treated as a column name, switching to the correct dialect usually fixes it.

Common SQL mistakes formatting helps you spot

A formatter does not execute or fully validate your query, but clear layout makes many bugs obvious:

• A missing comma in the select list. SELECT id name FROM users is legal SQL, but it returns id under the alias name. With one column per line, the missing comma stands out.
• A filter on an outer-joined table in WHERE. LEFT JOIN orders o … WHERE o.status = 'paid' silently turns the outer join into an inner join. Move the condition into the ON clause if you want to keep unmatched rows.
• Mixed AND and OR without parentheses. AND binds more tightly than OR, so a OR b AND c means a OR (b AND c). Add parentheses to make intent explicit.
• Unbalanced parentheses or quotes. When the output indentation suddenly drifts, look for an unclosed bracket or string literal just before that point.

Tips and best practices

• Uppercase keywords are a widespread convention because they separate SQL syntax from your table and column names; lowercase is equally valid. Pick one per project.
• Always alias tables in multi-table queries and qualify column names (u.id rather than id).
• Never build SQL by concatenating user input. Use parameterised queries or prepared statements to prevent SQL injection.
• Storing timestamps as integers? Use the Unix timestamp converter to check what a value means, and the UUID generator for test primary keys.

Frequently asked questions

Does formatting change what my query does?

No. The formatter only changes whitespace, line breaks and, if you choose, keyword case. Identifiers, string literals and the logic of the query are unchanged.

Does the SQL formatter check whether my query is valid?

Not fully. It tokenises the query to lay it out, so badly broken input may produce odd output, but it does not check that tables or columns exist or that the statement would run. Use your database or an EXPLAIN for that.

Can I format several statements at once?

Yes. Separate statements with semicolons and each one is formatted in turn.

Should SQL keywords be uppercase?

SQL keywords are case-insensitive in all major databases, so it is purely a style choice. Uppercase is traditional and common in documentation; many modern teams prefer lowercase. Consistency is what matters.