SQL Formatter and Minifier
Format messy SQL into readable indented clauses or minify it to one line, with keyword casing options and support for the common dialects.
A minifier that tidies its own output will tidy your string literals too
Minifying used to mean joining every token with a space and then cleaning up the joined text — drop the space after an open parenthesis, before a comma, and so on. Those substitutions ran over the whole string, and a quoted literal is part of the whole string.
| Literal as written | Came out as | Now |
|---|---|---|
'( hello )' | '(hello)' | '( hello )' |
'a , b' | 'a, b' | 'a , b' |
'x ; y' | 'x; y' | 'x ; y' |
'a . b' | 'a.b' | 'a . b' |
'Smith , John' | 'Smith, John' | 'Smith , John' |
'see ( note )' | 'see (note)' | 'see ( note )' |
The SQL still parses. The data it inserts is different, and all six literals above came out altered. The fix is not a better regular expression — it is to decide the spacing while the tokens are still tokens, so nothing ever inspects the finished text. Once you flatten structured input into a string, every rule you write afterwards applies to the parts you meant and the parts you did not.
None of the 13 ordinary statements checked alongside them changed,
apart from one thing that fell out of the same rewrite: deleting the space
after an open parenthesis had always left the one before it, so
count(*) came back as count (*). That affected
5 of the 13 — 7 characters of
padding, in a minifier.
Minifying has to delete line comments, not preserve them
This looks like data loss and is the opposite. A double-dash comment runs to the end of its line, and minifying puts everything on one line.
| Result | |
|---|---|
| Comment kept | select id , -- the primary key name from users |
| Comment dropped | select id, name from users |
Keep it and the query selects one column instead of two, because everything after the dashes is now inside the comment. Dropping it is the only behaviour that preserves what the SQL does. Block comments go the same way.
Quoting is the part the tokeniser gets right
Keywords are uppercased, but only when they are keywords. A column called
select in quotes comes through untouched, because the tokeniser knows
it is holding a string rather than a word.
| Written | Minified |
|---|---|
select "select" from t | select "select" from t |
select `from` from t | select `from` from t |
select 'from' from t | select 'from' from t |
It follows the ANSI escape — a quote is doubled to include it, as in
'it''s' — which is what SQLite, Postgres and SQL Server use.
MySQL's backslash escape is not recognised, and the damage is worse than a short
literal: the rest of the statement gets swallowed by a second string that never
closes.
A number here is digits with an optional decimal part, and nothing else. Of the
five forms tested, 2 are read as
one number; scientific notation, hex and a leading-dot literal each come apart
into two tokens. Nothing is lost — the same characters come back out — but a
formatter that thinks e6 is a column name will treat it like one.
How to use
- Paste your SQL query.
- Choose an indentation style and keyword case.
- Review the formatted output.
- Copy it back into your editor or migration.
Frequently asked questions
Why does formatting SQL matter?
Because a long query is read far more often than it is written, and an unformatted one hides its own structure. Putting each clause on its own line makes the joins, filters and grouping visible at a glance, which is where most query bugs are found.
Should keywords be uppercase?
It is the dominant convention and worth following for that reason alone. Uppercase keywords separate the language from your table and column names visually, which helps considerably in long queries. SQL itself is case-insensitive for keywords, so it is purely a readability choice.
Does formatting affect performance?
Not at all. Whitespace and casing are discarded before the query is planned. The one caveat is that some databases cache query plans keyed on the exact text, so reformatting can cause a one-time recompile — an effect measured in milliseconds and only on the first execution.
Why does my query fail after formatting?
Almost always a string literal or a quoted identifier that got altered. Formatters should leave the contents of quotes untouched, but a dialect mismatch — particularly around square brackets, backticks and dollar-quoted blocks — can cause a mangle. Check anything inside quotes first.
Do the SQL dialects differ enough to matter?
Yes. Identifier quoting alone differs between double quotes, backticks and square brackets depending on the database, and each has its own extensions for limits, string functions and date handling. A formatter set to the wrong dialect can misread perfectly valid SQL.
Where should the comma go in a select list?
Leading commas — at the start of each line — make it obvious when one is missing and let you comment out the last column without breaking the syntax. Trailing commas read more naturally. It is a genuine style argument with no correct answer, so pick one and be consistent.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.