SQL Formatting Best Practices: 10 Rules (Free Formatter)

Good SQL formatting is mostly about making a query's structure obvious at a glance: keywords in one case, each clause on its own line, one column per line, clear aliases and consistent indentation. You can apply most of it in one click with the free SQL formatter, which handles PostgreSQL, MySQL, SQL Server, Oracle, BigQuery, Snowflake and more, then follow the few rules a formatter can't decide for you.

Here's the query we'll use throughout, as it often arrives from a log or a colleague:

select o.id, c.name as customer, sum(i.qty * i.price) total from orders o join customers c on c.id = o.customer_id left join order_items i on i.order_id = o.id where o.status = 'paid' and o.created_at >= '2026-01-01' group by o.id, c.name having sum(i.qty * i.price) > 1000 order by total desc limit 10

1. Pick one keyword case and stick to it

Upper-case keywords (SELECT, FROM, WHERE) with lower-case table and column names is the most common convention, because it separates the language from your data at a glance. Lower-case everything is also popular in some teams and tools. Either is fine; mixing is not.

In the formatter, the Keywords option offers UPPER, lower or As typed. It applies to function names (SUM, COUNT) and data types too.

2. One clause per line

Start each major clause on a new line: SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. Your eye can then jump straight to "what's the filter?" or "how is it grouped?". Here's our query after pressing Format with UPPER keywords, 2-space indent and the PostgreSQL dialect:

SELECT
  o.id,
  c.name AS customer,
  SUM(i.qty * i.price) total
FROM
  orders o
  JOIN customers c ON c.id = o.customer_id
  LEFT JOIN order_items i ON i.order_id = o.id
WHERE
  o.status = 'paid'
  AND o.created_at >= '2026-01-01'
GROUP BY
  o.id,
  c.name
HAVING
  SUM(i.qty * i.price) > 1000
ORDER BY
  total DESC
LIMIT
  10

Same query, same result, but now you can review it.

3. One column per line in long SELECT lists

With columns stacked, adding, removing or commenting out one is a one-line change, and code-review diffs show exactly which column changed. For two or three short columns, one line is fine; past that, stack them.

4. Always write AS for column aliases

Notice SUM(i.qty * i.price) total above. It works, but the alias is easy to miss, and a forgotten comma between two columns silently turns the second into an alias of the first:

SELECT name email FROM users   -- one column, called "email"

Writing AS every time (SUM(i.qty * i.price) AS total) makes intent clear and turns that typo into something a reviewer will spot. The formatter keeps your aliases as you wrote them, so this one is up to you.

5. Use short, meaningful table aliases

o, c and i work in a small query because they're the first letters of orders, customers and order_items. In a query with eight joins, prefer ord, cust, item, and never a, b, c assigned in join order. And once a query has more than one table, prefix every column with its alias, so nobody has to guess where status comes from.

6. Put each condition on its own line, with AND/OR first

The formatter starts each AND and OR on a new line, at the beginning. Lining up the operators on the left makes the logic scannable and makes it easy to comment out one condition while testing. When you mix AND and OR, add brackets even where precedence makes them optional; a OR b AND c means a OR (b AND c), which is rarely what people intended.

7. The leading-comma debate

Some people write:

SELECT
    id
  , name
  , email

The argument for leading commas: commenting out the last column doesn't leave a dangling comma, and missing commas jump out. The argument against: it reads oddly, and most formatters and style guides use trailing commas. Our formatter uses trailing commas. Our advice: let the team's formatter decide and stop debating it. Consistency matters more than which side wins.

8. Indent subqueries and CTEs

Nested queries should look nested. The formatter indents a subquery inside its brackets:

WHERE
  u.id IN (
    SELECT
      user_id
    FROM
      bans
  )

When a subquery grows past a few lines, consider a common table expression (WITH paid_orders AS (...)) instead. Named steps read top to bottom like a recipe.

9. Choose the right dialect

Each database has its own syntax: backticks in MySQL and BigQuery, square brackets in SQL Server, :: casts in PostgreSQL, QUALIFY in Snowflake. If the formatter says it "couldn't be read", pick the matching option under Dialect before anything else. The tool supports 14 options, from Standard SQL to ClickHouse.

10. Keep comments, and know what minify does

Comments explaining why a filter exists are worth more than any formatting. Formatting keeps them. Minify is different: it puts the query on one line and drops comments, so use it only for copies (a log line, a config value, a one-line test), never for the source file. If you need the query inside a string in code, the free string escaper has a SQL option for quotes. For real application code, use your database library's query parameters rather than building SQL from strings.

Make SQL formatting a habit

• Format before every code review, so diffs show logic changes, not spacing.
• Agree a team style once (keyword case, indent, comma position) and write it down.
• Use the same settings every time; to check two versions of a query really differ only in layout, format both and compare them with the text compare tool.

Format a query now

Paste your SQL into the free SQL formatter, pick the dialect, keyword case and indent, and press Format. It changes only spacing and letter case, never what the query does, and your SQL stays on your device.

More for developers: free browser tools for developers and why you should never paste secrets into online tools.