SQL Minifier: Shrink Query Size Before Sending It to Production

A formatted SQL query is easy for a person to read and hard to embed anywhere else. A SQL minifier collapses that same query to one line — stripping indentation, line breaks, and comments — without changing a single thing about what the query does. Line breaks and repeated spaces between keywords carry no meaning to the database; a query that fits on one line and one that's spread across twenty parse to the exact same statement. That's the inverse of the other half of this job — pretty-printing — and both directions, along with SQL's formatting rules in full, are covered in the SQL Formatter guide. Format when a person needs to read the query; minify — or compress SQL, the other phrase people search for the same operation, or turn a query into a single line for whatever needs a one-liner — when only the query's size and shape as a string matters.

• Embedding a query as a string literal in application code.A multi-line, indented query assigned to a string variable either forces ugly indentation onto the surrounding code or gets reformatted by a linter that doesn't know it's looking at SQL. A one-line query sidesteps both problems.
• Keeping migration files and logs compact. A migration tool or a query logger that writes every executed statement to disk accumulates noise fast if each entry is pretty-printed — minified SQL keeps that output scannable and small.
• Fitting a query into a size-constrained field. A URL query parameter, an environment variable, or a database column with a real length limit benefits from every whitespace byte and comment removed — headroom you get back for free.
• Diffing generated SQL.When a query is built by an ORM or a template and checked against an expected value in a test, comparing single-line strings avoids diff noise from formatting differences that don't reflect an actual change in behavior.

The one thing worth being exact about: not all whitespace in a SQL query is insignificant. The spaces between SELECT, FROM, and a table name are formatting and can be collapsed freely. The spaces inside 'Hello World'are data — remove or collapse them and you've silently changed the string a query inserts or compares against. The same problem applies to a quoted identifier: "Order Date"is a single column name containing a literal space, and a minifier that doesn't recognize the quotes will happily mangle it into something that no longer matches any column. A regex pass that blindly replaces runs of whitespace with a single space, or strips it entirely, can't tell the difference between these two cases — it sees characters, not the structure the characters belong to.

-- source
INSERT INTO logs (message) VALUES ('Hello   World');

-- naive: collapses every run of spaces, including inside the string
INSERT INTO logs (message) VALUES ('Hello World');
-- wrong: three spaces became one — the stored value changed

Getting this right requires actually tokenizing the SQL — walking through it character by character, recognizing where a string literal or quoted identifier starts and ends, and only collapsing whitespace that falls outside those boundaries. Anything treated as regex-level find-and-replace on raw text will eventually hit a case like this and quietly corrupt a value.

A minifier also has to remove both comment styles SQL supports — -- line comments that run to the end of the line, and /* block comments */ that can span several. That sounds like a job for two regexes until a value inside the query happens to contain the same characters a comment starts with. A comma-separated notes field containing a literal --, or a JSON blob stored in a text column containing /*, is real data, not the start of a comment — and a minifier that matches comment syntax without tracking whether it's currently inside a string literal will delete part of a value it should have left alone.

UPDATE tickets SET note = 'discount -- expires end of month' WHERE id = 42;

-- a regex-only minifier sees "--" and truncates the string here:
UPDATE tickets SET note = 'discount
-- wrong: half the string was deleted as if it were a trailing comment

The fix is the same one as before: track string and identifier boundaries while scanning, and only treat -- or /*as the start of a real comment when the scanner is outside any quoted region. Here's what correct minification looks like end to end — comments removed, line breaks and indentation collapsed, every literal left exactly as written:

-- fetch active orders placed this month
SELECT
  o.id,
  o.customer_id,
  o.total
FROM orders o
WHERE o.status = 'active' /* excludes cancelled and refunded */
  AND o.placed_at >= '2026-08-01'
ORDER BY o.placed_at DESC;

↓

SELECT o.id, o.customer_id, o.total FROM orders o WHERE o.status = 'active' AND o.placed_at >= '2026-08-01' ORDER BY o.placed_at DESC;

GenKitLab's SQL Minifier works this way: it tokenizes the query before collapsing anything, strips both comment styles without ever touching a string literal or quoted identifier, and runs entirely in your browser — nothing you paste is uploaded anywhere. If you need to go the other direction — turn a one-line query back into something readable to review or debug — SQL Formatter is the same operation, run in reverse.