Skip to content
Tools

SQL Minifier

Minify SQL queries instantly while preserving query functionality and improving portability. Everything runs locally in your browser.

Visible pane

Original

0 chars

Loading editor…

Waiting for SQL

ANSI SQL

What is SQL minification?

Minifying SQL means removing everything the database does not read: the indentation, the line breaks, the runs of spaces and — usually — the comments. What is left is the same statement written in the smallest number of characters that still parses.

A formatted query and its minified form
-- Active customers and what they have spentSELECT  u.id,  u.name,  SUM(o.total) AS revenueFROM users uLEFT JOIN orders o ON o.user_id = u.idWHERE u.active = 1GROUP BY u.id, u.name; SELECT u.id,u.name,SUM(o.total)AS revenue FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.active=1 GROUP BY u.id,u.name;

Both run identically. SQL is insensitive to whitespace, so the database parses the two into exactly the same statement and builds exactly the same plan. The second is around 40% smaller.

Everything runs in your browser. The queries people paste into these tools carry table names, column names and often real values, so nothing is uploaded, stored or logged.

Why minify SQL queries?

Worth saying plainly first: minifying does not make a query run faster. The database parses the string before it plans the query, and parsing a shorter string is not measurably cheaper. Anyone claiming a performance win from minification is selling something.

What it does save is everywhere the query has to go as text:

  • Bytes over the wire. A query sent on every request in a hot path is bandwidth you pay for repeatedly.
  • Room in a value. Configuration fields, environment variables and query parameters have limits, and a multi-line string needs escaping in almost every format that holds one — percent-encoding for a URL, backslashes for JSON.
  • Space in a log line. A one-line query stays one log entry instead of twenty, which is the difference between grep finding it and not.
  • Size on disk. Across a dump of thousands of statements, comments and indentation are a real fraction of the file.
  • Noise in a string literal. A query embedded in application code reads better as one line than as a ladder of concatenated fragments.

The honest summary: minify SQL that is being transmitted or stored, and keep the formatted version as the one people read and edit.

How SQL minification works

Naively, minifying looks like a search and replace: collapse the whitespace, strip anything between /* and */, done. That approach breaks on the first query that contains a string.

Everything a careless minifier gets wrong
SELECT 'hello   world' AS greeting,      -- three spaces are part of the value       '-- not a comment' AS marker,     -- this is data, not a comment       "my  column",                     -- a quoted name, spaces and all       '/* also data */' AS payloadFROM t;

Every one of those has to survive untouched. So the tool does not work on text at all: it tokenises the query first, exactly as a database would, and then rewrites only the gaps betweentokens. A space inside a string is part of a token, so no option can reach it. That makes “preserve string literals” a structural guarantee rather than a promise.

Tokenising is also what makes the dialect matter. A backtick is a name on MySQL and nothing special on PostgreSQL. A # starts a comment on MySQL and is part of a name elsewhere. $$ opens a body on PostgreSQL that runs until the next $$, apostrophes and semicolons included.

Once tokenised, three rules decide the output:

  • Keep a separator only where removing it would join two things. a , b becomes a,b because a comma already separates them, but x = 1 AND y keeps the space around AND — without it the number and the keyword would fuse into one word.
  • Never create a comment by accident. 1 - -2 closed up to 1--2 comments out the rest of the statement. Those two minus signs stay apart, and so does anything that would form /*.
  • Never remove a comment that is not one. An optimiser hint changes the plan and a MySQL /*! block is executable SQL. Both are kept by default.

Finally, the query is validated before it is minified. If a quote is never closed or a parenthesis has no partner, minification is refused — because the output would not be a smaller query, it would be a different one.

Supported SQL dialects

Nine engines, and the difference that matters to a minifier is always the same one: which characters open something that must not be touched. Read a quote wrongly and a name becomes a string, or a string becomes forty tokens, and everything after it is wrong too.

The same name, quoted four ways
SELECT `my  column` FROM t;   -- MySQL, MariaDB, BigQuerySELECT "my  column" FROM t;   -- PostgreSQL, Oracle, SQLiteSELECT [my  column] FROM t;   -- SQL Server-- In all three the double space is part of the name and survives minification.

Pick an engine in the options, or leave detection on and let the query speak for itself. A query with nothing distinctive in it stays ANSI rather than being guessed at.

MySQL

Backticked names, # as a second comment marker, and backslash escapes inside strings. Its /*! … */ comments are not comments at all — MySQL executes what is inside them, so they are preserved by default.

PostgreSQL

Double-quoted names and $$ … $$ dollar-quoted bodies, which can contain anything at all including apostrophes and semicolons. Getting that wrong would turn a whole function body into a hundred stray tokens.

SQL Server

Square-bracketed names, which nothing else uses. [my column] holds a space that is part of the name, and treating it as whitespace would silently rename the column.

Oracle

The home of the optimiser hint. /*+ INDEX(users idx_users_name) */ reads like a comment and behaves like an instruction, so removing it changes the plan the database picks.

SQLite

A small dialect with few surprises for a minifier — standard quoting, standard comments. The usual care around string literals is all that is needed.

MariaDB

MySQL's fork and near enough identical in the ways that matter here: backticks, # comments and the same executable-comment syntax.

Snowflake

Standard quoting, but a vocabulary of its own — QUALIFY, VARIANT, LATERAL FLATTEN — which matters for validating a query before minifying it rather than for the minifying itself.

BigQuery

Backticked names that usually hold a full `project.dataset.table` path, dots and hyphens included. The whole thing is one token and survives untouched.

Minification features

Comment removal

Single-line -- comments and multi-line /* */ comments are independent switches, so you can strip the explanatory prose off a migration while keeping a licence header, or the reverse. Keep single-line comments while removing line breaks and a break is put back after each one — everything following a -- on its line is inside it, so without that break the rest of the query would be commented out. Optimiser hints and MySQL executable comments are held back from removal by default.

Whitespace reduction

Three separate controls, because “remove the whitespace” means different things to different people. Remove extra spaces drops the ones that are not needed at all, so a , b becomes a,b. Collapse multiple spaces turns runs into single spaces while leaving the structure alone. Trim leading and trailing spaces drops indentation from any line break that survives.

Empty line removal

With line breaks kept, a run of blank lines collapses to one break — which is what turns a generated script with a paragraph gap between every statement into something compact but still reviewable line by line.

SQL validation

Run before minification, not after. An unterminated string, an unclosed comment or an unbalanced parenthesis blocks the output entirely, with the line, the column and a caret pointing at the character. Warnings — a DELETE with no WHERE, a missing final semicolon, a mistyped keyword — are reported without blocking anything.

Compression statistics

Characters, words, lines and UTF-8 size for the input; characters, lines and size for the output; then the ratio, the bytes saved and the time it took. Sizes are in bytes rather than characters, because bytes are what crosses a wire — the two differ the moment a comment contains an accent. If the output comes out larger, which can happen to a query that was already minimal, the panel says so rather than rounding the bad news to zero.

Common use cases

Production deployment

Migration and seed scripts shipped as one line each are smaller in the artefact, quicker to transfer and unambiguous in a deployment log that wraps at eighty columns.

Embedded SQL

A query living inside application code as a string literal. Minified, it survives being pasted into a single line without the escaped newlines and ragged indentation a formatted query brings with it.

Configuration files

Query values in YAML, JSON or an environment variable, where a multi-line string needs block scalars or escaping. One line sidesteps the whole problem.

Data migration

Long generated scripts full of repeated statements, where comments and indentation from the generator are pure overhead and the file has to move between machines.

Code optimisation

Trimming what crosses the wire on every request in a hot path. It does not make the database faster — see the FAQ — but it does cut what you send and store.

SQL backups

Dumps and archived schemas, where stripping comments and indentation off thousands of statements takes a meaningful bite out of a file you keep forever.

SQL formatter vs SQL minifier

They are the same engine pointed in opposite directions. One spends bytes to make a query readable; the other spends readability to save bytes. Neither changes what the query does, so the only question is who is going to read the result next — a person, or a wire.

A comparison of the SQL formatter and the SQL minifier
 SQL FormatterSQL Minifier
What it optimises forA person reading the queryThe number of bytes
What it does to whitespaceAdds it, to expose the structureRemoves all of it that is not load-bearing
What it does to commentsKeeps them where they were writtenRemoves them, unless you say otherwise
Typical size changeLarger — often much larger30–50% smaller on a hand-formatted query
Reach for it whenReviewing, debugging, or committing a query to a repositoryEmbedding, transmitting or storing a query
Effect on the query planNoneNone — provided hints survive, which they do by default
Is it reversible?Yes, minify it againYes, beautify it again — except for removed comments

In practice most teams use both, in one direction each way: the formatted query is what lives in the repository and gets reviewed, and the minified one is what gets embedded or shipped. Because minification removes formatting rather than information, you can move between them at will — the SQL formatter turns a minified query back into something readable, and the only thing that cannot come back is a comment you chose to remove.

Frequently asked questions

Is this SQL minifier free?

Yes. Minifying, beautifying, validating, uploading, downloading and every option are free, with no account, no sign-up and no cap on how many queries you process.

Is my SQL uploaded anywhere?

No. The query is tokenised and minified by JavaScript running in your browser. Nothing is sent to a server, nothing is stored and nothing is logged. You can disconnect from the network after the page loads and the tool keeps working — which matters, because the queries people paste into these tools routinely contain table names, column names and sometimes real values from production.

Will minification change what my query does?

No. Only the whitespace between tokens is ever rewritten, plus any comments you asked to remove. SQL is insensitive to whitespace, so the minified query parses to exactly the same statement and produces exactly the same plan. The one thing that would change behaviour — dropping an optimiser hint or a MySQL executable comment — is prevented by default.

What happens to spaces inside my strings?

Nothing. They are untouchable, and structurally so rather than as a promise: the tokeniser knows exactly where every string literal, quoted name and comment begins and ends, and the minifier only ever rewrites the gaps between tokens. A space inside 'hello world' is part of a token, so no option here can reach it. The same goes for a newline inside a string and for a -- that appears inside one.

Can I remove SQL comments?

Yes, and the two kinds are independent switches. Single-line -- comments and multi-line /* */ comments can each be removed or kept. If you keep single-line comments while removing line breaks, a line break is put back after each one — everything following a -- on its line is inside the comment, so without that break the rest of the query would be commented out.

What are SQL hints and why are they preserved?

An optimiser hint like /*+ INDEX(users idx_users_name) */ looks like a comment but tells the database which plan to use, so removing it silently changes how the query runs. MySQL's /*! … */ is worse: MySQL executes what is inside it, so removing it removes real SQL. Both are kept by default for that reason. You can turn hint preservation off if you are sure you want them gone.

Why does it refuse to minify my query?

Because it found an error that would make the output a different query rather than a smaller one. An unclosed quote means everything after it is inside a string the author never opened; an unbalanced parenthesis means the grouping is not what it looks like. Minifying either would produce something that is smaller and wrong. Warnings — a DELETE with no WHERE, a missing final semicolon — do not block anything.

Can I beautify SQL again after minifying it?

Yes. The Beautify tab reformats the same query with proper indentation, one clause per line and one column per line. Minification removes formatting, not information, so the query can be laid out again at any time — the only thing that cannot come back is a comment you chose to remove.

Can I upload a .sql file?

Yes. Use the upload button or drag a .sql file anywhere onto the tool. The file name is shown above the input panel and is reused when you download the result, so a folder of minified files stays sorted. Files are read as UTF-8, so accented and non-Latin text in comments and literals survives intact.

Does it support stored procedures?

Yes. A procedure body is just more tokens as far as the minifier is concerned — BEGIN … END blocks, DECLARE statements, IF branches and loops all minify like anything else, and the semicolons that separate statements inside the body are never removed.

Does it support all SQL dialects?

It supports ANSI SQL, MySQL, MariaDB, PostgreSQL, SQL Server, Oracle, SQLite, Snowflake and BigQuery. The dialect matters because it decides how quoting and comments are read: backticks are names on MySQL and BigQuery, square brackets are names on SQL Server, dollar-quoted bodies are strings on PostgreSQL, and # starts a comment only on MySQL and MariaDB. Getting that wrong would turn a name into a string.

How does dialect detection work?

Each dialect has a list of markers and the one with the most evidence wins. A backtick, AUTO_INCREMENT and ENGINE=InnoDB together mean MySQL; SERIAL and JSONB mean PostgreSQL; square brackets and GETDATE() mean SQL Server. A query with no distinguishing marks stays ANSI rather than being guessed at, because guessing wrong changes how quotes are read.

How much smaller will my SQL get?

It depends almost entirely on how much comment and indentation the original carried. A hand-formatted query with a comment block on top often drops 30–50%. A query that was already one line may only lose a few percent — and occasionally the output is a byte or two larger, because tokens that were touching in the source needed a separator to stay apart. The statistics panel reports whichever way it went.

Does minifying SQL make it run faster?

No, and it is worth being clear about that. The database parses the query before it plans it, and parsing a shorter string is not measurably cheaper than parsing a longer one. What minification saves is transmission and storage: bytes over the wire, room in a configuration value, space in a log line, and the size of a string embedded in application code.

Can I keep the line breaks and just tidy the spacing?

Yes. Turn off “remove line breaks” and every line survives — only the spacing within each one shrinks, blank lines collapse and indentation is trimmed. That produces a compact but still readable script, which is often what you want for a migration file that has to be reviewed as well as run.

What happens to the semicolons?

They are kept by default. Turning off “preserve semicolons” drops only the final one, which is what you want when embedding a single query in code that adds its own terminator. The semicolons between statements are never removed — they are not punctuation, they are what stops two statements from becoming one.

How large a script can it handle?

Up to about 10 MB of text. Minification is debounced so typing stays responsive, large scripts are processed on a background thread so the page never freezes, and the scanner makes a single pass with no recursion. The editor only highlights what is on screen, which is what keeps scrolling through a multi-megabyte dump smooth.

Can I search inside a large script?

Yes. The search button, or Ctrl/Cmd+F, opens a search over the input with every match highlighted, a match counter, and previous and next buttons to step through them. It searches whatever is in the panel — keywords, table names, column names, function names or literal values. Escape closes it.

Are there keyboard shortcuts?

Ctrl/Cmd+Enter minifies, Ctrl/Cmd+Shift+B beautifies, Ctrl/Cmd+Shift+C copies the output, Ctrl/Cmd+Shift+D downloads it, Ctrl/Cmd+Shift+L loads another sample, Ctrl/Cmd+Shift+Delete clears the input, and Ctrl/Cmd+F opens the search. Escape closes the search.

Does it work offline?

Once the page has loaded, yes. Everything runs locally, so you can disconnect and keep minifying. A connection is only needed to load the page the first time.

Popular tools

↑ ↓Navigate↵OpenEscClose