SQL Formatter and Minifier
Formatting puts SELECT / FROM / WHERE / JOIN clauses on separate lines, indents subqueries inside parentheses and lists AND / OR per line; minifying strips comments and extra whitespace down to one line.
SQL formatting rearranges a statement squeezed onto one line into something readable: the main clauses each on their own line, the SELECT list one column per line, subqueries indented inside their parentheses, and AND and OR listed separately. The reverse compresses it by stripping extra whitespace and comments, which suits configuration files and log lines. Being able to read a statement quickly matters when reviewing someone else's query or chasing a slow one.
Two expectations to set. This tool reworks whitespace according to a keyword table and builds no syntax tree, so it will not check that parentheses are balanced or that a table exists, and it will not complain about dialect differences — the upside being that common MySQL, PostgreSQL and Oracle syntax all go through. And minifying removes comments, with a line comment taking the rest of the line with it, so keep to formatting when comments matter.
Did this tool solve your problem?
Submitting sends the tool name, your input and the current result to the server. Please do not include ID numbers, phone numbers or other private data.
AI assistant It answers using your current input and result
Asking again sends your current input and result to the server once more. Please do not include private data.
How to use
- Paste the SQL.
- Format it into clauses and indentation, or minify it onto one line.
- Read subqueries and boolean chains clause by clause.
- Use formatting rather than minifying when comments must survive.
How it works
A token-based formatter, not a parser
This tool reflows whitespace by keyword tables and token rules — no syntax tree: it won't check parenthesis balance or table existence, and won't error on misspelled keywords. The benefit is stability: whether your SQL is MySQL, PostgreSQL or Oracle dialect, the layout stays predictable — no "parser met an unknown dialect and gave up" behavior.
Which parentheses break lines
Whether parentheses break and indent depends on a SELECT inside: subqueries like IN (SELECT ...) break and indent one level to expose nesting, while COUNT(*) and IN (1, 2, 3) stay on one line, keeping short expressions from shattering.
Why minification removes comments
Line comments (-- xxx) extend to end of line; minifying to one line must drop them first, or they'd comment out everything after. Block comments /* */ behave the same. So minification deletes comments by default — keep them by formatting instead, or with the keep-comments option.
Code example
SQL Before and after formatting
-- Before formatting
select u.id,u.name,count(o.id) as cnt from users u left join orders o on o.user_id=u.id where u.status=1 and o.created_at>='2026-01-01' group by u.id,u.name order by cnt desc limit 10;
-- After formatting
SELECT
u.id,
u.name,
COUNT(o.id) AS cnt
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.status = 1
AND o.created_at >= '2026-01-01'
GROUP BY u.id, u.name
ORDER BY cnt DESC
LIMIT 10;
SQL Companion: check whether the index is used
-- MySQL: look at the execution plan, especially type and key
EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 1;
-- PostgreSQL
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 100;
-- Tip: keep the formatted SQL in your team docs — easier to search and review than a screenshot
FAQ
Does formatting change SQL semantics?
No. Only whitespace moves and keyword case adjusts; strings, numbers and identifiers stay byte-identical, and no semicolons are added or removed. The one substantive change: minification deletes comments — harmless to execution, but lost to future readers.
Does it support MySQL / PostgreSQL / Oracle dialects?
Formatting-wise, all of them: the tool knows no dialect semantics, just the common keyword table — LIMIT, RETURNING, :: casts, backtick and bracket identifiers all format fine. If a rare keyword isn't uppercased, it's not in the table — a display nuance, not an error.
Can keywords keep their original case?
Yes — set keyword case to "keep as-is". The choices are preserve, uppercase and lowercase, applying only to keywords in the table; table names, column names and strings are never touched.
Do comments stay in place after formatting?
Line and block comments survive on their own lines (or in their original multi-line shape), but don't automatically indent with the code they annotate. If comments vanished, you minified — switch to formatting mode.
Will minification glue two statements together?
No. Semicolons are statement boundaries and survive; adjacent words like SELECT a FROM t always keep at least one space — never SELECTa. Minification removes only extra whitespace and comments.
Why did the subquery indent but the function call didn't?
The rule is whether SELECT appears inside the parentheses: subqueries break to expose nesting, while function calls and IN lists stay on one line because they're usually short and read better intact. The test runs per parenthesis, and nesting indents level by level.
Will a SELECT inside a string be uppercased?
No. Single-quoted strings, double-quoted identifiers and backtick identifiers are tokenized whole and skip keyword processing — in SELECT 'select me', the quoted text stays as written and only real keywords change case.
Is my SQL uploaded?
No. Tokenizing and layout happen entirely in the browser — no network requests, so the server never sees your schema or statements. No history is written; closing the page clears everything.