Compact SQL without losing the literal data

An SQL minifier turns spacious, commented SQL into a tighter representation that is easier to embed, transmit, snapshot, or compare. This online SQL minifier works directly from the Raw SQL Query editor and updates the read-only Minified SQL Query panel as you type. It removes layout whitespace around selected punctuation, collapses remaining whitespace, and can strip common SQL comment forms. It does not send the statement to a database, rewrite its logic, or claim that a smaller query executes faster.

The important distinction is between formatting characters and data characters. A newline between SELECT and FROM is layout. A space inside 'New York' is data. The minifier tracks single-quoted and double-quoted regions so their contents remain intact, including doubled quote escapes such as 'don''t' and "odd""name". That makes it useful for ordinary scripts containing text values and quoted identifiers, while still leaving several dialect-specific cases for manual review.

A practical minification pass

Paste a complete statement or a semicolon-separated script into Raw SQL Query. The output appears immediately; there is no Run button. The Strip SQL Comments (--, /* */, #) checkbox is enabled initially. Leave it selected when comments are disposable, or clear it when optimizer hints, generated markers, or documentation must remain.

Three measurements appear after input is present:

Original Size is the UTF-8 byte count of the source.
Minified Size is the UTF-8 byte count of the current result.
Compression Ratio reports the percentage saved, displayed as “smaller.”

These are byte measurements, not JavaScript character counts, so non-ASCII text can occupy more than one byte. Copy places the current result on the clipboard. Download saves it as query.min.sql. Clear empties both editors and hides the metrics. Copy and Download remain disabled until there is output.

For a release workflow, first minify with comments enabled, inspect the result, then test that exact downloaded file against the target database in a non-production environment. Keep the readable source under version control; treat minified SQL as a derived artifact.

What the transformation actually does

Outside quoted text, tabs, newlines, and repeated spaces become at most one space. Spaces immediately after ( or , are omitted. A pending space immediately before (, ), ,, ;, or = is removed. The tool therefore converts:

-- account lookup
SELECT  u.id,  u.display_name
FROM users AS u
WHERE u.status = 'active user'
  AND u.region = "North America";

into:

SELECT u.id,u.display_name FROM users AS u WHERE u.status= 'active user' AND u.region= "North America";

Notice the precise output rather than assuming aggressive token joining. The algorithm removes a space before =, but it does not remove the space after =. It also preserves both spaces inside the quoted values. This is SQL whitespace compression, not canonical SQL formatting and not query optimization.

If comment stripping is disabled, comment markers are retained. Whitespace inside those retained comments is still processed by the general whitespace rules because the tool only enters comment-tracking mode when stripping is on. For a comment-preserving archival copy, compare the output carefully; the readable original remains the safer source of documentation.

Comments: useful text or executable metadata?

The checkbox recognizes three starts outside quotes: /* for a block, -- for a line comment, and # for a line comment. Block content is discarded through the next */. Line content is discarded through a carriage return or newline, where a separating space is inserted. A marker inside 'literal -- text' or "identifier#part" is preserved because quoted regions take precedence.

Not every comment is semantically irrelevant. MySQL version comments such as /*! STRAIGHT_JOIN */, optimizer hints such as /*+ INDEX(...) */, migration-tool directives, and checksums embedded by deployment systems may influence execution or tooling. With Strip SQL Comments selected, they are removed like any other block comment. Disable stripping or avoid this tool for scripts where comments carry machine-readable instructions.

The # rule is broad: any unquoted hash starts a line comment. That matches common MySQL usage but may conflict with another SQL-like language or templating syntax. Likewise, PostgreSQL dollar-quoted function bodies are not recognized as strings. A -- inside $$...$$ can therefore be mistaken for a comment. Dialect-aware review is mandatory for stored routines and generated SQL.

Where compact SQL earns its place

Minification is valuable when a query must live in a constrained configuration field, a fixture, a migration bundle, an HTTP request sample, or a golden test snapshot. It can reduce noise in telemetry where the full statement is intentionally recorded, although production logging should parameterize or redact sensitive values first. It also makes whitespace-insensitive comparisons easier when a team wants to see substantive query changes.

It is less useful in application source. Humans diagnose joins, predicates, and subqueries more safely when clauses remain on separate lines. Database engines tokenize whitespace efficiently, and removing comments or line breaks generally does not improve the execution plan. For prepared statements, network and parse overhead are usually addressed by parameterization, connection behavior, and plan caching rather than SQL minification.

A sound implementation workflow keeps three layers separate: maintain formatted SQL, produce compact SQL only at the packaging boundary, and validate the artifact with the real database dialect. If a template engine supplies values, minify the static template before interpolation only when the template syntax is known to survive the pass.

Boundaries and failure modes

This utility is a character scanner, not an SQL parser. It does not verify keywords, resolve identifiers, balance parentheses, infer a dialect, or execute a statement. Valid-looking output can still reference a missing table, use a reserved word incorrectly, or contain a destructive predicate.

Review these cases before relying on the result:

Backtick-quoted identifiers are not tracked. Comment markers inside backticks may be stripped.
PostgreSQL dollar quotes, Oracle alternative quoting, bracketed identifiers, and escape-string variants receive no special handling.
A backslash-escaped quote is not treated as an escape; doubled quotes are supported.
An unclosed quote causes the remainder to be preserved as quoted content rather than reported as an error.
An unclosed block comment, when stripping is enabled, discards everything after its opening marker.
Removing a comment can expose adjacent tokens if the source relied on the comment itself as a separator.
SQL client commands, delimiters, and templating placeholders are not modeled.

For complex migrations, stored procedures, trigger definitions, or vendor scripts, use a dialect-specific formatter/minifier and run parser or database validation afterward. Never substitute minification for parameterized queries: compacting WHERE email = '${email}' does nothing to prevent injection.

Verification checklist

Start with a representative file containing strings, quoted identifiers, comments, joins, nested expressions, and multiple statements. Compare source and result clause by clause. Run both in a disposable database with the same schema and parameters, then compare result sets or affected-row counts inside a rolled-back transaction. For data-changing SQL, inspect transaction boundaries and retain backups.

Check the compression figures only after correctness. A low ratio is not a defect; already compact SQL has little removable material. A high ratio may simply indicate extensive comments, which is a reason to inspect what was discarded. Store query.min.sql only if your build or deployment process requires an artifact, and regenerate it from the authoritative formatted file rather than editing it manually.

Questions developers ask

Does this make a query run faster?

Usually not. It reduces source bytes and visual layout, not joins, indexes, cardinality, or the database execution plan. Use EXPLAIN, indexes, statistics, and query design for performance work.

Are spaces inside values removed?

No. Content inside single or double quotes is copied as entered. Doubled quote characters are also retained.

Can I keep comments and still collapse whitespace?

Yes, by clearing Strip SQL Comments. Be aware that retained comment whitespace is processed like ordinary whitespace, so preserve the original if exact comment layout matters.

Which file does Download create?

The browser downloads the generated text as query.min.sql with a plain-text content type.

Is the output guaranteed valid for PostgreSQL, MySQL, SQL Server, or Oracle?

No. The scanner handles common quotes, whitespace, and comment markers but is not dialect-aware. Test the output with the exact engine and version that will execute it.

Why does the ratio count accented or non-Latin text differently?

The metrics use UTF-8 bytes. Many characters require multiple bytes, so byte size and visible character count are not identical.

SQL Minifier