SQL Formatter: Beautify and Indent SQL Queries

Long SQL queries crammed onto a single line are nearly impossible to read and debug. A SQL formatter transforms messy queries into well-structured, indented code that’s easy to understand at a glance.

Why Format SQL?

Before Formatting

SELECT u.id, u.name, u.email, o.order_id, o.total, o.created_at FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.active = true AND o.total > 100 ORDER BY o.created_at DESC LIMIT 50;

After Formatting

SELECT
  u.id,
  u.name,
  u.email,
  o.order_id,
  o.total,
  o.created_at
FROM
  users u
INNER JOIN
  orders o ON u.id = o.user_id
WHERE
  u.active = true
  AND o.total > 100
ORDER BY
  o.created_at DESC
LIMIT
  50;

The formatted version makes it immediately clear what columns are selected, which tables are joined, what conditions apply, and how results are ordered.

SQL Formatting Conventions

Keyword Placement

Major SQL keywords should start new lines:

SELECT ...
FROM ...
WHERE ...
GROUP BY ...
HAVING ...
ORDER BY ...
LIMIT ...

Column Lists

List columns vertically with consistent indentation:

SELECT
  user_id,
  first_name,
  last_name,
  email,
  created_at
FROM
  users

JOIN Clauses

Each JOIN gets its own line, with the ON condition:

FROM
  orders o
INNER JOIN
  users u ON o.user_id = u.id
LEFT JOIN
  products p ON o.product_id = p.id

WHERE Conditions

Each condition on its own line, with logical operators aligned:

WHERE
  u.active = true
  AND o.created_at > '2024-01-01'
  AND o.total > 50
  OR u.role = 'admin'

Subqueries

Indent subqueries to show nesting:

SELECT
  u.name,
  (
    SELECT
      COUNT(*)
    FROM
      orders o
    WHERE
      o.user_id = u.id
  ) AS order_count
FROM
  users u

Keyword Casing

SQL keywords are case-insensitive, but consistent casing improves readability. Two common conventions:

UPPERCASE Keywords (Traditional)

SELECT id, name FROM users WHERE active = TRUE ORDER BY name;

This is the most traditional style and makes keywords stand out clearly from column and table names.

lowercase Keywords (Modern)

select id, name from users where active = true order by name;

Some teams prefer lowercase for a less “shouty” feel, especially in code editors with syntax highlighting.

Both are valid — pick one and be consistent across your codebase.

How to Use Our SQL Formatter

1. Paste your SQL query in the left panel
2. Select keyword casing: UPPERCASE or lowercase
3. View the formatted output instantly in the right panel
4. Copy the result with one click

What the Formatter Handles

• SELECT statements with column splitting
• FROM / JOIN clause separation
• WHERE conditions on separate lines
• GROUP BY / ORDER BY clause formatting
• INSERT, UPDATE, DELETE statements
• Subqueries with proper indentation
• Keywords: SELECT, FROM, WHERE, JOIN, ON, AND, OR, GROUP BY, ORDER BY, HAVING, LIMIT, INSERT, INTO, VALUES, UPDATE, SET, DELETE, CREATE, ALTER, DROP, UNION, CASE, WHEN, THEN, ELSE, END, AS, IN, BETWEEN, LIKE, IS, NOT, NULL, EXISTS, DISTINCT, and more

Tips

• The formatter works with any SQL dialect (MySQL, PostgreSQL, SQLite, SQL Server)
• Keywords are recognized regardless of their original casing
• String literals and quoted identifiers are preserved as-is
• Comments are preserved during formatting

Formatting for Different Contexts

Code Reviews

Well-formatted SQL in code reviews helps reviewers understand the query logic:

-- Easy to review: each clause is clear
SELECT
  p.name,
  SUM(oi.quantity) AS total_sold,
  AVG(oi.price) AS avg_price
FROM
  products p
INNER JOIN
  order_items oi ON p.id = oi.product_id
WHERE
  oi.created_at >= '2024-01-01'
GROUP BY
  p.name
HAVING
  SUM(oi.quantity) > 10
ORDER BY
  total_sold DESC

Documentation

Formatted SQL in documentation helps readers understand data models and common queries without having to mentally parse dense one-liners.

Debugging

When a query returns unexpected results, formatting helps you isolate which clause might be wrong — is it the JOIN condition, the WHERE filter, or the GROUP BY?

Frequently Asked Questions

Does formatting change what the query does? No. SQL formatting only affects whitespace and line breaks. The query’s behavior is identical before and after formatting.

Should I format SQL in production code? Yes, use formatted SQL in your source code for readability. For dynamically generated queries sent to the database, the whitespace doesn’t affect performance.

What about query performance? Formatting has zero impact on query performance. The database parser ignores whitespace. Focus on proper indexing, query plans, and join strategies for performance.

Can I use this with ORMs? If your ORM generates raw SQL for debugging (like Django’s queryset.query or Rails’ to_sql), you can paste that output into the formatter to make it readable.

---

Try our free SQL Formatter to beautify your SQL queries instantly.