How to Format SQL Queries: Style Rules That Actually Matter

Why SQL formatting matters

SQL is read far more often than it is written. A query is written once and reviewed, debugged, optimized, and inherited by colleagues dozens of times. Poorly formatted SQL hides logic bugs, makes JOINs hard to audit, and turns 30-second debug tasks into 10-minute hunts.

Unlike application code, SQL doesn't have a universal formatter enforced by a linter in CI pipelines. Formatting is discretionary — which means it varies wildly between developers and databases. These rules represent the most widely agreed-upon conventions.

The fundamental rules

1. Capitalize SQL keywords

SQL is case-insensitive for keywords — select and SELECT both work. But capitalizing keywords creates an immediate visual separation between SQL structure and your own identifiers:

-- Bad
select id, name, email from users where active = 1

-- Good
SELECT id, name, email FROM users WHERE active = 1

2. One clause per line

Each major clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY) starts on its own line:

-- Bad
SELECT id, name FROM users WHERE active = 1 ORDER BY name

-- Good
SELECT id, name
FROM users
WHERE active = 1
ORDER BY name

This makes it immediately obvious how many clauses the query has and lets you spot a missing WHERE before accidentally running an unfiltered query.

3. Align SELECT columns and JOIN conditions

When selecting multiple columns, align them vertically so you can scan the list quickly:

SELECT
  u.id,
  u.name,
  u.email,
  o.total,
  o.created_at
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.active = 1

The leading comma style (comma at the start of the line) makes it easy to comment out a single column during debugging without touching adjacent lines.

4. Indent subqueries

Subqueries should be indented relative to their parent:

SELECT *
FROM users
WHERE id IN (
  SELECT user_id
  FROM orders
  WHERE total > 100
)

Without indentation, the subquery boundary is invisible in long queries and the logic becomes impossible to follow.

5. Alias meaningfully

Table aliases should be predictable abbreviations, not single letters (except for trivial self-joins):

-- Bad
SELECT a.id, b.name FROM users a JOIN orders b ON a.id = b.user_id

-- Good
SELECT usr.id, ord.name
FROM users usr
JOIN orders ord ON usr.id = ord.user_id

JOIN formatting

JOINs are where query complexity lives — and where bugs hide. Format them consistently:

SELECT
  u.name,
  p.title,
  c.name AS category
FROM users u
INNER JOIN posts p ON u.id = p.author_id
INNER JOIN categories c ON p.category_id = c.id
LEFT JOIN post_tags pt ON p.id = pt.post_id
WHERE u.active = 1
  AND p.published = 1

Each JOIN is on its own line. The ON condition appears on the same line as the JOIN for short conditions, or indented below for long ones. The JOIN type (INNER, LEFT, RIGHT) is always explicit — never just JOIN without the type qualifier.

WHERE clause formatting

Boolean conditions in WHERE are aligned with each condition on its own line:

WHERE u.active = 1
  AND u.created_at > '2025-01-01'
  AND (
    u.country = 'US'
    OR u.country = 'CA'
  )

The leading AND/OR makes it easy to comment out individual conditions during debugging. Grouped conditions use explicit parentheses even when not strictly required — operator precedence bugs from missing parentheses are common.

When to use the online formatter

The free SQL formatter is useful for:

• Inherited queries: When you receive a minified or poorly formatted query from a log, ORM output, or a colleague and need to read it immediately
• Code review: Paste raw SQL from a PR, format it, and review the logic with proper visual structure
• Database console output: Some database clients export queries in a single-line format — paste and format before analyzing
• Documentation: Format queries before pasting them into README files, Confluence pages, or Notion docs

SQL formatting in different databases

The rules above apply universally. Dialect-specific variations to be aware of:

• MySQL: Backtick identifiers (`column`) instead of double quotes. LIMIT at the end instead of TOP at the start.
• PostgreSQL: Double-quote identifiers ("Column"). Dollar-quoting for functions ($$...$$).
• SQL Server: Square bracket identifiers ([Column]). TOP n instead of LIMIT n.
• SQLite: Generally lenient — accepts most syntax variants but lacks some advanced features.

Related tools

• Free SQL Formatter — format and beautify SQL queries instantly in your browser
• Free JSON Formatter — format JSON responses from database APIs

Written by Achraf A., founder of TheFreeAITools.