About SQL Formatter & Minifier
SQL Formatter & Minifier re-indents a query so joins, filters, and subqueries line up under the clause they belong to, and collapses it back to one line when a query has to live inside a string literal or a log field.
SQL formatting is dialect-sensitive in ways that plain text reformatting is not. MySQL backticks, PostgreSQL dollar-quoted bodies, SQL Server bracketed identifiers, and dialect-specific keywords all change how a token should be treated. Selecting the dialect that matches your database is what separates a reliable reformat from one that mangles an identifier.
How to use this developer tool
- Paste the query, stored-procedure body, or logged statement into the input area.
- Select the dialect that matches the database that will execute it, such as MySQL, PostgreSQL, or SQLite.
- Format the query and read the clause structure from the indentation: each join condition and filter should sit under its own clause.
- Check quoted identifiers and string literals in the output against the original, since those are the parts a formatter is most likely to disturb.
- Copy the formatted query into your migration or review, or minify it when it needs to be embedded in code.
Worked example: an unreadable reporting query
A query pasted out of an ORM log arrives on one line. Formatting makes the join order and the filter placement visible, which is what you actually need in review.
select o.id,c.name,sum(i.qty*i.price) total from orders o join customers c on c.id=o.customer_id left join items i on i.order_id=o.id where o.created_at>='2026-01-01' and c.region in ('eu','uk') group by o.id,c.name having sum(i.qty*i.price)>1000 order by total desc limit 50SELECT
o.id,
c.name,
SUM(i.qty * i.price) total
FROM
orders o
JOIN customers c ON c.id = o.customer_id
LEFT JOIN items i ON i.order_id = o.id
WHERE
o.created_at >= '2026-01-01'
AND c.region IN ('eu', 'uk')
GROUP BY
o.id,
c.name
HAVING
SUM(i.qty * i.price) > 1000
ORDER BY
total DESC
LIMIT
50Once the clauses are stacked, the LEFT JOIN followed by a HAVING on the aggregated value stands out: rows with no matching items are grouped, then filtered away by the HAVING. That is a correctness question the one-line version hides.
Dialect details that affect formatting
| Dialect | Quoted identifier | String literal |
|---|---|---|
| MySQL / MariaDB | `order` | 'text' (double quotes also allowed) |
| PostgreSQL | "order" | 'text' and $$body$$ |
| SQL Server / T-SQL | [order] | 'text', N'unicode' |
| SQLite | "order" or [order] | 'text' |
| Oracle PL/SQL | "ORDER" | 'text', q'[text]' |
Troubleshooting
A column name is uppercased and the query then fails.
Why it happens In PostgreSQL an unquoted identifier folds to lowercase, while a quoted one is case-sensitive. Changing the case of a quoted identifier changes which column it refers to.
Fix Turn off keyword-casing, or confirm that the formatter left quoted identifiers untouched. Compare the output against the original for every quoted name.
A dollar-quoted function body is broken apart.
Why it happens PostgreSQL bodies delimited by $$ or $tag$ contain a whole nested program. A formatter using a different dialect does not recognize the delimiter and formats the inside as if it were the outer statement.
Fix Select the PostgreSQL dialect. For long procedural bodies, format the body separately and paste it back between the delimiters.
Placeholders such as ? or :name are moved or removed.
Why it happens Parameter markers differ by driver. A marker the selected dialect does not know can be tokenized as an operator.
Fix Format the statement with the parameters substituted by literal sample values, then reintroduce the markers in the final version.
Formatting succeeds but the query no longer returns the same rows.
Why it happens A formatter only rewrites whitespace and keyword case. If the result differs, something was edited by hand during the copy, most often a truncated IN list or a lost line from a multi-statement paste.
Fix Diff the formatted output against a formatted copy of the original with the Text Compare tool rather than reading the two versions side by side.
When this tool is the right choice
- Making an ORM-generated or logged statement reviewable before it goes into a pull request.
- Standardizing indentation across a migration file so that later diffs show real changes.
- Reading someone else's reporting query well enough to reason about its joins.
- Compacting a query to a single line so it can be embedded in application code or a shell command.
When to use something else
- Checking that a query is valid for your schema. Only the database can resolve table and column names.
- Estimating performance. Use EXPLAIN against the real database with representative data.
- Rewriting a query into a different but equivalent form. Formatting never changes semantics, by design.
Privacy and data handling
The query is tokenized and re-printed in this browser tab. It is not executed, not sent to a database, and not transmitted to our servers. Production statements often embed customer identifiers and, in logged form, literal parameter values, so replace those with placeholders before pasting a statement you did not write yourself.
Related developer tools
Frequently asked questions
Does formatting change what the query does?
No. Only whitespace, line breaks, and optionally keyword case change. If the result behaves differently, the two texts differ for another reason, and a diff will show where.
Which dialect should I pick if I am not sure?
Pick the database that will actually run the statement. If the query uses no quoted identifiers, no procedural blocks, and no vendor functions, most dialects produce the same output and the choice does not matter.
Can it format several statements at once?
Yes, statements separated by semicolons are formatted in sequence. Procedural blocks that contain internal semicolons need the matching dialect so the block is recognized as one unit.
Why are my keywords uppercased?
Uppercase keywords against lowercase identifiers is the most widely used convention because it makes clause boundaries scannable. It is a display convention only; SQL keywords are case-insensitive in every major dialect.
Is it safe to paste a production query?
The text stays in your browser, but treat the content itself as the risk. Logged statements often carry literal values such as email addresses or account identifiers. Replace them with placeholders first.
Will minifying a query make it run faster?
No. The database parses the statement either way, and parse time is negligible next to planning and execution. Minify only when the query has to fit somewhere that dislikes newlines.