SQL Formatter: How to Format & Beautify SQL Queries

Poorly formatted SQL is hard to read, harder to debug, and almost impossible to review in a PR. A SQL formatter takes your raw query — however you wrote it — and applies consistent indentation, keyword casing, and line breaks. This guide covers the formatting rules, the best practices, and how to apply them in seconds.

Format SQL →SQL Cheatsheet →

Why SQL Formatting Matters

Databases don't care about whitespace — SELECT*FROM users WHERE id=1 and a beautifully indented equivalent execute identically. But humans do care. Unformatted SQL causes:

  • Harder debugging. A 10-join query on one line takes 5 minutes to find the wrong ON condition. Properly formatted, it's instant.
  • Missed logic errors. Deeply nested subqueries and WHERE clause conditions are easy to misread when not indented.
  • Poor code review. SQL stored in codebases (migrations, ORMs, raw queries) should be as readable as any other code.
  • Slow onboarding. New team members reading schema-heavy queries need structure to understand what the query is doing.

SQL Formatting Rules

Before formatting:

select u.id, u.name, o.total, o.created_at from users u inner join orders o on u.id = o.user_id where o.status = 'completed' and o.created_at >= '2026-01-01' order by o.created_at desc limit 50

After formatting:

SELECT u.id , u.name , o.total , o.created_at FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'completed' AND o.created_at >= '2026-01-01' ORDER BY o.created_at DESC LIMIT 50

The formatting rules applied above:

  • Uppercase keywords — SELECT, FROM, WHERE, JOIN, ON, AND, ORDER BY, LIMIT
  • Each major clause on its own line — SELECT, FROM, JOIN, WHERE, ORDER BY
  • Leading commas in SELECT list — easier to add/remove columns without touching the previous line
  • JOIN conditions indented under the JOIN keyword
  • AND/OR conditions indented under WHERE

SQL Formatting Best Practices

  • Always uppercase SQL keywords. SELECT, INSERT, UPDATE, DELETE, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT, UNION — these should always be uppercase. It's one of the most universally agreed-upon SQL conventions.
  • Lowercase table and column names. Unless your schema uses uppercase names (unusual), keep identifiers lowercase. Mixed-case queries like Select UserId FROM Users are harder to read than SELECT user_id FROM users.
  • Use table aliases for multi-table queries. Short, consistent aliases (u for users, o for orders) reduce visual noise and prevent ambiguous column references.
  • Explicit JOIN type. Write INNER JOIN or LEFT JOIN rather than just JOIN. It communicates intent clearly in code review.
  • Break long WHERE clauses vertically. Each AND/OR condition gets its own line, indented under WHERE. The boolean operator goes at the start of the line (leading AND), not the end.
  • Add comments for complex logic. -- Filter to completed orders in Q1 above a complex WHERE condition saves the next developer time.

Formatting Subqueries and CTEs

CTEs (Common Table Expressions) dramatically improve readability for complex queries compared to nested subqueries:

-- CTE: much more readable than a nested subquery WITH completed_orders AS ( SELECT user_id , SUM(total) AS lifetime_value FROM orders WHERE status = 'completed' GROUP BY user_id ) SELECT u.name , co.lifetime_value FROM users u INNER JOIN completed_orders co ON u.id = co.user_id ORDER BY co.lifetime_value DESC

Each CTE gets the same indentation treatment as a standalone query. This is automatically applied by a formatter like DevKit's SQL formatter.

Related Tools

SQL Formatter →
Format SQL queries with keyword uppercasing and indentation. 100% in-browser.
SQL Cheatsheet →
SELECT, JOINs, GROUP BY, window functions, subqueries — complete reference.
JSON Formatter →
Format JSON API responses alongside your SQL query results.
Text Diff Checker →
Compare two SQL queries side by side to spot differences.

FAQ

What is a SQL formatter?

A SQL formatter (also called a SQL beautifier or SQL pretty printer) takes a SQL query — often minified, poorly indented, or written on one line — and reformats it with consistent indentation, uppercase keywords, and line breaks that make it easy to read and maintain.

Does the DevKit SQL formatter send my queries to a server?

No. DevKit's SQL formatter runs 100% in your browser using JavaScript. Your queries — including any table names, column names, or data values — never leave your device. This makes it safe for production queries containing schema details or sensitive data.

Which SQL dialects does the formatter support?

DevKit's SQL formatter handles standard SQL that is compatible with MySQL, PostgreSQL, SQLite, SQL Server, and most other relational databases. Dialect-specific syntax (like PostgreSQL's :: cast operator or MySQL's backtick identifiers) may have limited support.

Should SQL keywords be uppercase?

Convention strongly favors uppercase SQL keywords (SELECT, FROM, WHERE, JOIN, etc.) and lowercase for identifiers (table names, column names). This makes queries much easier to scan — the eye quickly distinguishes SQL keywords from user-defined names. Most SQL formatters uppercase keywords by default.

How do I format a long SQL query for readability?

Key formatting rules: (1) each major clause on a new line (SELECT, FROM, WHERE, GROUP BY, etc.), (2) align columns in the SELECT list with leading commas, (3) indent joined tables under the FROM clause, (4) indent WHERE conditions, (5) uppercase keywords. Use a formatter tool to apply these automatically.