Skip to content
Browse tools
SQL formatter & minifier

Readable SQL in, tight SQL out.

A real parser, not a regex. Beautify messy queries, minify them for transport, strip comments, convert keyword casing, lint for unbalanced brackets, and wrap the result in a string literal for your language. Everything runs locally — nothing is uploaded.

Input
1
Output
1
Formatted SQL appears here.
in 0 B out 0 B change lines 0 statements 0 tokens 0 status ready
Drop it into your codebase

Embed as a string literal

Takes whatever is currently in the output pane and escapes it for your language, quotes and backslashes handled.

Language
Faster without the mouse

What this tool does

Format

Tokenises the statement properly, so strings, comments, quoted identifiers and dollar-quoted blocks are never mangled. Clauses break onto their own lines, joins align, subqueries indent, and CASE blocks nest.

Minify

Collapses to the shortest safe form, keeping a space only where removing it would change meaning. Comments can be stripped or kept, and the status bar shows exactly how many bytes you saved.

Case conversion

Keywords, functions and identifiers each get their own casing rule, so you can uppercase SELECT while leaving customer_id exactly as written.

Lint

Flags unclosed brackets, unterminated strings, runaway block comments, trailing commas before FROM, and missing final semicolons — before your database does.

Dialects

Backticks for MySQL, square brackets for SQL Server, $$ blocks and :: casts for PostgreSQL, plus # comments where the dialect allows them.

Keyboard

⌘/Ctrl + Enter format · ⌘/Ctrl + M minify · ⌘/Ctrl + Shift + C copy output · Tab inserts an indent inside the editor rather than moving focus.

Reference

Formatting conventions used here

These are the defaults. Every one of them is adjustable in the options panel above.

RuleWhat happensWhy
Clause keywordsStart a new line at the current nesting levelMakes the shape of a query scannable at a glance
SELECT listOne column per line, indented onceKeeps diffs to a single line when a column is added
JOIN … ONJOIN at clause level, ON indented below itSeparates what you're joining from how
AND / ORNew line, indented under the conditionPredicate order becomes reviewable
SubqueriesBracket opens, contents indent, bracket closes on its own lineNesting depth is visible without counting brackets
Short bracketsStay inline when under the wrap widthIN (1, 2, 3) gains nothing from three lines
CASE blocksWHEN and ELSE indent, END returns to the CASE levelBranches line up so a missing one is obvious
StatementsSeparated by a blank line after each semicolonScripts read as a sequence rather than a wall
Questions

Common questions

Is my SQL sent anywhere?
No. The parser, formatter and minifier all run in your browser as plain JavaScript. There is no network call at any point, which is the main reason this is safe to use with production queries that contain real table names, schemas or embedded values.
Why minify SQL at all?
Three common reasons: shrinking queries that travel over the wire on every request, fitting a statement into a single line for a log entry or a config value, and normalising whitespace so two queries can be compared for equality. It also strips comments, which matters if those comments mention internals you don't want shipped to a client.
Will minifying change how my query behaves?
It shouldn't. Whitespace outside of string literals and quoted identifiers is not significant in SQL, and the minifier keeps a space wherever removing one would join two tokens together. The one thing to watch is comments: line comments run to the end of a line, so if you keep them while collapsing everything onto one line, the parser preserves the newline after each one rather than commenting out the rest of your query.
Does it validate my SQL?
It lints rather than validates. It will catch unbalanced brackets, unterminated strings, unclosed block comments and trailing commas — the structural mistakes that stop a statement parsing at all. It does not know your schema, so it cannot tell you a column is misspelled or a join condition is wrong.
Should keywords be uppercase?
It's a convention, not a rule — SQL keywords are case-insensitive. Uppercase keywords with lowercase identifiers is the most widely used style because the contrast makes structure pop without any syntax highlighting. Some modern teams prefer all-lowercase for a quieter look. What matters is that a codebase picks one, which is why keyword, function and identifier casing are three separate settings here.
Leading or trailing commas?
Trailing commas read more naturally. Leading commas make it harder to leave a dangling comma behind when you delete the last column of a SELECT, which is a genuinely common error, and they keep version-control diffs to one line. Both are supported.
Copied
Drop a .sql file to load it