SQL Formatter
Whitespace and keyword case only — the statement you get back means exactly what you pasted. String literals, quoted identifiers and comment text are never touched. Nothing is uploaded; the whole thing runs in your browser.
About SQL Formatter
Pulls a one-line statement apart: every SELECT / FROM / WHERE / GROUP BY gets its own line, clause bodies are indented by level, and keywords get a consistent case.
The real value is a clean diff. When the whole query sits on one line, changing a single condition shows up as one line deleted and one line added — the reviewer can't tell what you actually touched. Once formatted, untouched clauses stay untouched and the change lands on exactly one line. Formatting isn't about looking tidy; it's about making edits visible.
You have to pick the dialect. SQL has no single standard: MySQL uses backticks and LIMIT n, SQL Server uses TOP n and [name], Oracle uses ROWNUM and whole BEGIN ... END; PL/SQL blocks, PostgreSQL has ::type casts and RETURNING. Picking the wrong one rarely errors out — it just treats LIMIT as an ordinary identifier or splits a PL/SQL block at the /, which looks fine and won't run.
Layout only. String literals, quoted identifiers and comment text are carried through untouched. No renaming, no keyword completion, no expanding SELECT *, no rewriting the plan. It isn't a syntax checker either — broken SQL still formats, just not always the way you'd like.
A full mysqldump doesn't belong here: the browser parses the whole thing, and anything over 2 MB is refused. Use pg_format or the CLI sql-formatter at that size.
Frequently asked questions
Does formatting change what the query does?
No. Only whitespace, line breaks and keyword case change. String literals, identifiers and comment text are preserved byte for byte, and the execution plan is unaffected by layout.
Why do I have to choose a dialect?
Keywords and grammar differ. LIMIT in MySQL, TOP in SQL Server and ROWNUM in Oracle get treated as ordinary words under the wrong dialect, so line breaks land in the wrong place — and PL/SQL blocks get split at the slash.
Can it format SQL that has syntax errors?
Yes. It works from tokens and common clause structure without validating grammar, so broken SQL still comes out — the indentation just may not be what you'd want. Don't use it to check whether SQL is correct.
Are comments removed?
No. Both -- line comments and / / block comments are kept as written; they move with the clause they belong to.
Is my SQL uploaded anywhere?
No. The formatter library loads on this page and everything runs in your browser. The server never sees your statements.
Why isn't CASE WHEN aligned into columns?
It indents by syntax level, not by column. Column alignment requires measuring the widest expression first, and one field change in a long statement re-flows the whole block — which makes the diff worse, not better.
