SQL Formatter
A lightweight SQL formatter. Paste a cramped, one-line query and get it back with each major clause on its own line, keywords cased consistently, and conditions indented — so you can actually read and review it. Runs in your browser; it formats for readability rather than parsing the full SQL grammar.
SELECT u.id,
u.name,
COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
ON o.user_id = u.id
WHERE u.active = 1
AND u.country IN ('US','CA')
GROUP BY u.id,
u.name
HAVING COUNT(o.id) > 3
ORDER BY orders DESC
LIMIT 10A query’s logic is unchanged by its layout, but your ability to read it is not. A correct SELECT crammed onto one line hides its own structure — you cannot see at a glance which columns come back, what is being joined, or where the filter lives. Formatting does not touch what the database does; it just makes the shape visible to the human reviewing it.
The moves are simple and mechanical. Put each major clause — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY — on its own line so the skeleton stands out. Uppercase the keywords so they separate visually from your table and column names (SQL does not care about case, but your eyes do). Indent the members: columns under SELECT, conditions under WHERE with AND and OR aligned so the boolean logic reads like an outline. Suddenly a wall of text becomes a scannable structure.
This tool does exactly that pass and no more — it is a lightweight, dialect-agnostic formatter, not a full SQL parser, so it nails everyday queries and leaves string literals alone, while very deep subqueries or vendor-specific syntax may not indent perfectly. That is the right trade for a quick readable copy before you paste a query into a review, a ticket, or a migration. For heavy work, a dialect-aware formatter in your database tool goes further.
How it works
- Each major clause on its own line, keywords uppercased.
- Conditions and columns indented for scannability.
- Leaves string literals and quoted identifiers untouched.
- Lightweight and dialect-agnostic — readability, not full parsing.
Frequently asked questions
What does the formatter actually do?
It normalizes whitespace, uppercases the standard SQL keywords, and puts each major clause — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, LIMIT — on its own line, then indents the pieces under them (columns after SELECT, conditions after WHERE with AND/OR aligned). The result is the same query, laid out so a human can scan its structure at a glance instead of parsing a single long line.
Does it change what my query does?
No — it only reformats whitespace and keyword casing, which are not significant to the SQL engine (outside of string literals and quoted identifiers, which it leaves untouched). The query you get back is semantically identical to the one you pasted; it just reads better. Always keep the meaning intact: formatting is presentation, not a rewrite.
Is this a full SQL parser?
No, and that is a deliberate trade-off. It is a lightweight, dialect-agnostic formatter that recognizes common keywords and structure, which handles the large majority of everyday SELECT/INSERT/UPDATE queries well. Deeply nested subqueries, window functions, CTEs and vendor-specific syntax may not indent perfectly. For those, a dialect-aware formatter in your IDE or database tool will do better — this is for a quick, readable pass.
Why uppercase keywords?
It is a long-standing convention that makes queries easier to read by visually separating the SQL keywords (SELECT, WHERE, JOIN) from your identifiers (table and column names). It is purely stylistic — SQL keywords are case-insensitive — but consistency helps reviewers spot the shape of a query quickly. If your team prefers lowercase, the important thing is that everyone does the same thing.