Keywords:
Indent:
Commas:

Input — paste your SQL

Output — formatted SQL

Further reading: SQL formatting best practices
All formatting is done in your browser. No SQL queries are sent to any server.

How SQL Formatting Works

SQL is whitespace-insensitive — a database executes select*from users identically to a properly indented multi-line query. In production code, however, unformatted SQL is difficult to read, review, and debug. A SQL formatter applies consistent structure: major clauses on new lines, subqueries indented, keywords in a consistent case, and columns aligned for readability.

This formatter handles SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE, and DROP statements. It correctly handles subqueries, CASE expressions, JOIN clauses, and WITH CTEs. Use the JSON Formatter if your SQL returns JSON columns and you need to inspect the output.

Worked Example

Unformatted input

select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.total>100 order by o.total desc limit 10

Formatted output

SELECT
    u.id,
    u.name,
    o.total
FROM users u
INNER JOIN orders o
    ON u.id = o.user_id
WHERE o.total > 100
ORDER BY o.total DESC
LIMIT 10

Comma Placement — End vs Start

The "end" style places commas at the end of each line — natural writing order. The "start" style places commas at the beginning, making it easy to comment out a column without leaving a trailing comma that breaks the query. Many style guides including GitLab's SQL style guide prefer leading commas for exactly this reason.

Want the full guide?Read SQL Formatting Best Practices — a side-by-side comparison of the GitLab, dbt Labs, Mozilla, and SQLFluff style guides, plus a 10-rule quick-reference cheat sheet.

When to Use Uppercase vs Lowercase Keywords

SQL keywords are case-insensitive. The traditional convention is uppercase keywords with lowercase identifiers, which makes query structure visible at a glance. Some modern style guides prefer all lowercase for cleaner appearance in ORM code. Use the preserve option when you want to change indentation without altering existing keyword casing.


Frequently Asked Questions

Does this SQL formatter support MySQL, PostgreSQL, and SQLite?
Yes — this formatter handles standard SQL syntax common across MySQL, PostgreSQL, SQLite, SQL Server, and Oracle. Dialect-specific syntax like PostgreSQL's :: cast operator or MySQL's backtick identifiers is preserved without modification. The formatter focuses on indentation and keyword casing rather than dialect-specific rewriting.
Why do some developers prefer leading commas in SQL?
With leading commas, each column line is self-contained and can be commented out without affecting adjacent lines. With trailing commas, removing the last column requires editing two lines. Many SQL style guides, including those at large engineering organizations, mandate leading commas for easier editing and cleaner version control diffs.
Does formatting SQL change how it executes?
No. SQL is whitespace-insensitive — the database ignores spaces, tabs, and newlines between tokens. Formatting is purely cosmetic and has no effect on query execution, performance, or results. A formatted query and an unformatted query with identical logic produce identical results.
What is a CTE and how should it be formatted?
A CTE (Common Table Expression) is a named temporary result set defined with WITH name AS (...) before the main query. CTEs make complex queries more readable by breaking them into named logical steps. CTEs are supported in PostgreSQL, MySQL 8+, SQLite 3.35+, and SQL Server.
Can this tool format stored procedures or multi-statement SQL?
The formatter handles individual SQL statements and simple multi-statement batches separated by semicolons. Complex stored procedures with procedural logic (BEGIN...END, IF...ELSE) are partially supported — the SQL statements within them will be formatted, but the procedural wrapper may not indent perfectly.
Is it safe to paste my SQL queries into this tool?
Yes — all formatting runs entirely in your browser. Your SQL is never sent to any server. This makes it safe to paste queries containing sensitive table names, column names, or literal values. The tool has no database connection and cannot execute queries — it only reformats text.