English
Beautify SQL queries with syntax-aware indenting.
Last updated
A SQL formatter takes dense, single-line, or auto-generated SQL and rewrites it with consistent indentation and line breaks. Developers and analysts reach for it when reviewing joins, debugging filters, cleaning up ORM output, sharing queries in tickets or documentation, and stepping through query plans.
Formatting does not change what a query *does* — it changes how easily a human can read it. Once the layout is consistent, the relationship between SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, and ORDER BY becomes much easier to inspect, especially in queries that mix subqueries and CTEs.
SQL has many *dialects* — PostgreSQL, MySQL, SQLite, T-SQL (Microsoft SQL Server), Oracle, and BigQuery all extend the standard with their own syntax. A good formatter understands the dialect you choose so it doesn't break vendor-specific syntax.
SELECT chooses columns, FROM chooses tables, WHERE filters rows, GROUP BY aggregates, and ORDER BY sorts.RETURNING, LIMIT, TOP, and bracketed identifiers ([col] vs "col") are not portable across databases.Drop your SQL into the input box. Single-line, ORM-generated, or partially formatted SQL all work.
Choose PostgreSQL, MySQL, SQLite, or T-SQL so the formatter respects vendor-specific keywords like LIMIT, TOP, or RETURNING.
Pick keyword case (uppercase is standard) and indent width (2 or 4 spaces). Most teams pick uppercase keywords + 2-space indent.
Each clause sits on its own line, joins are aligned, and subqueries are indented. Comments are preserved.
Paste the formatted query into your migration, ORM raw query, or BI tool. Everything stays in your browser.
The clauses you'll see in 95% of SELECT queries, in the order they're processed conceptually. Vendor references: PostgreSQL SELECT, MySQL SELECT.
| Clause | Purpose | Example |
|---|---|---|
SELECT | Pick which columns/expressions to return | SELECT id, name |
FROM | Pick the source table(s) | FROM users |
JOIN ... ON | Combine rows from another table | JOIN orders ON orders.user_id = users.id |
WHERE | Filter rows before grouping | WHERE active = true |
GROUP BY | Aggregate rows that share values | GROUP BY country |
HAVING | Filter aggregated groups | HAVING COUNT(*) > 10 |
ORDER BY | Sort the result set | ORDER BY created_at DESC |
LIMIT / OFFSET | Paginate the result | LIMIT 20 OFFSET 40 |
WITH ... AS | Common Table Expression (CTE) — name a subquery | WITH active AS (...) |
select id,name from users where active=true order by created_at desc limit 10SELECT id, nameFROM usersWHERE active = trueORDER BY created_at DESCLIMIT 10;Each clause is now on its own line and the column list is indented. Reviewing this query in code review just got 10× easier.
select u.name,o.total from users u join orders o on o.user_id=u.id where o.total>100SELECT u.name, o.totalFROM users uJOIN orders o ON o.user_id = u.idWHERE o.total > 100;Aliasing tables (users u, orders o) keeps the column list short. The JOIN ... ON line makes the relationship between tables explicit.
select * from users where id in (select user_id from enrollments where course_id=5)SELECT *FROM usersWHERE id IN ( SELECT user_id FROM enrollments WHERE course_id = 5);Indenting the inner query shows the dependency clearly. Many subqueries can be rewritten as JOINs or CTEs once the structure is visible.
LIMIT 10 in PostgreSQL, TOP 10 in T-SQL, and FETCH FIRST 10 ROWS ONLY in standard SQL all do the same thing.SELECT, FROM, WHERE) and lowercase identifiers, because the visual contrast makes the query structure pop. Pick one style and stay consistent.