SQL Minifier
Collapse a SQL query to one line and strip comments, without touching string literals, quoted identifiers or the meaning of the query.
SQL
Minified
Paste a query to collapse it to a single line.
Minifying runs in your browser — the query is never uploaded. It is tokenised rather than pattern-matched, so string literals, quoted identifiers and the spacing inside them are left exactly as written.
About the SQL Minifier
Collapse a formatted SQL query onto one line and strip its comments. The usual reason is that the query has to live somewhere that does not tolerate newlines: a JSON config value, a one-line log entry, an environment variable, a CI parameter, or a database client that turns a multi-line paste into a dozen separate statements.
This SQL minifier tokenises the query rather than pattern-matching it, which is the whole difference between a tool you can trust with a `WHERE` clause and one you cannot. String literals, quoted identifiers and comments are recognised as single units, so a `--` inside a string is never mistaken for a comment, the spaces inside `'New York'` are never collapsed, and a semicolon inside a literal never splits a statement.
Spacing around operators is deliberately kept. Removing it saves a handful of bytes and can invent a token that was not there: `a - -1` becomes `a--1`, which is a line comment, and everything after it on the line disappears. Minification that changes what a query does is not minification, so this one stops short of that.
- Tokenised, so literals, quoted identifiers and comments are never mangled
- Line and block comments removed, with optimiser hints flagged before they go
- One line per statement, or the whole script on one line
- Keyword case left alone, upper-cased or lower-cased
- PostgreSQL, MySQL and SQL Server identifier quoting all understood
- Byte counts before and after, in UTF-8
How to use it
- Paste your query on the left.
- Choose whether to strip comments — read the warning first if any of them look like optimiser hints.
- Pick a keyword case if you want the output normalised as well as collapsed.
- Copy the single-line result.
- Use the SQL formatter to expand it again when you next have to read it.
Real-world use cases
Backend & API developers
Fit a query into a JSON config value, a CI environment variable, or a database client that treats a multi-line paste as several statements — without breaking the WHERE clause in the process.
DevOps & platform engineers
Collapse a migration or seed script into a single line for a shell one-liner or a Kubernetes ConfigMap value, where an embedded newline is either invalid or needs its own escaping.
Data engineers
Strip comments and whitespace from a generated query before logging it, so a log line stays on one line instead of wrapping across a dozen in whatever's tailing the output.
QA & test engineers
Normalize a captured query to one line before diffing it against an expected string in a test assertion, so the comparison isn't sensitive to incidental formatting.
DBAs
Minify a query for a statement cache keyed on exact text, where two differently-formatted copies of the same query would otherwise miss each other's cache entry.
Examples
A formatted query on one line
SELECT
id,
name
FROM users
WHERE active = true;SELECT id, name FROM users WHERE active = true;
Whitespace between tokens carries no meaning in SQL, so this parses identically. Whitespace inside a literal is another matter entirely.
Whitespace inside a string survives
SELECT * FROM t WHERE city = 'New York'
SELECT * FROM t WHERE city = 'New York'
A regular expression that collapses runs of whitespace changes this query's results. Tokenising is the only way to know which spaces are formatting.
-- inside a string is not a comment
SELECT '-- not a comment' AS note
SELECT '-- not a comment' AS note
A naive comment stripper deletes the rest of the line here and leaves an unterminated string behind.
Function calls stay tight, column lists do not
SELECT count(*) FROM users; INSERT INTO users (id, name) VALUES (1, 'a');
SELECT count(*) FROM users; INSERT INTO users (id, name) VALUES (1, 'a');
Whether a space precedes a `(` is how you tell a function call from a column list, so the tokenizer records it and the minifier preserves the distinction.
Common errors
| Message | Cause | Fix |
|---|---|---|
| The database rejects the minified query | Almost always a retained line comment. A `--` comment runs to the end of the line, so putting one on a single-line query comments out everything after it. | Strip comments, which is the default. If you must keep them, the output puts a line break after each one — do not remove it. |
| The query planner chose a different plan | A removed optimiser hint. Oracle reads `/*+ ... */` and MySQL reads `/*! ... */` as instructions rather than comments. | The tool warns when the comments it removed look like hints. Keep comments for those queries. |
| Two statements ran as one | A missing semicolon between them, which was invisible while they sat on separate lines. | Leave One line per statement on. The statement count above the input pane tells you how many the tokenizer found. |
| Identifiers were case-folded | Keyword casing is applied only to recognised keywords, but a column named `select` or `order` is indistinguishable from one. | Quote reserved words as identifiers, or leave keyword case as written. |
| The saving is small | The query is mostly literals and identifiers rather than indentation. | Expected. Minifying SQL is about fitting it somewhere, not about bytes — unlike JSON, nothing here is sent over the wire at volume. |
Frequently asked questions
›Is my query uploaded anywhere?
No. Tokenising and minifying happen in your browser. Queries frequently embed table names, schema details and literal customer values; none of it leaves the page, and nothing is stored or logged.
›Does minifying change what the query does?
No. Only whitespace between tokens is removed, and only where removing it cannot merge two tokens into one. Comments are removed if you ask for it — which does change behaviour on Oracle and MySQL, where certain comments are optimiser hints, so the tool warns when the ones it removed look like hints.
›Will it make my query faster?
No. The database parses the query in microseconds and whitespace is discarded before anything is planned. The one place it can matter is a statement cache keyed on exact text — normalising formatting can improve the hit rate there, but that is a caching effect, not a parsing one.
›Why are spaces kept around operators?
Because closing them up can create a token that was not there. `a - -1` becomes `a--1`, which starts a line comment and silently truncates the query; `a / *b` becomes `a/*b`, which opens a block comment. The saving is a few bytes and the failure is silent, so the trade is not worth making. `::` is the exception, since Postgres casts are conventionally written tight and cannot form a comment.
›Can it minify a whole migration file?
Yes. Statements are split on semicolons that are genuinely statement terminators — a semicolon inside a string or a comment does not count — and each one goes on its own line. Note that dollar-quoted function bodies in PostgreSQL are not parsed as a unit, so a file full of `$$ ... $$` blocks is not a good candidate.
›How do I get the formatting back?
Paste the minified query into the SQL formatter. Both tools share the same tokenizer, so a query survives the round trip — you lose only the comments, if you chose to strip them.
›Does it work on a whole file with multiple dialects mixed in?
The dialect setting only changes which identifier-quoting and parameter styles the tokenizer recognises — it does not reject the others. Double-quoted, backtick and bracketed identifiers, and $1, ?, :name and @name parameters are all tokenised regardless of the setting, so a file with statements written for more than one database still minifies correctly.
›What is the difference between this and just removing newlines with a regex?
A regex has no idea what it is looking at: it collapses the spaces inside 'New York' along with the indentation, and it cannot tell a -- inside a string from an actual comment. This tool tokenises the query first, so literals, quoted identifiers and comments are recognised as whole units before anything is removed — the same reason the SQL formatter and SQL query explainer trust the same engine to read a query correctly.
Last updated