SQLite Query Minifier & Formatter
Minify collapses a statement onto one line and deletes every comment style -- --, # and block comments -- so it is a shrinker, not an optimiser: nothing about the query plan changes, and anything an audit trail relies on is gone. Pick SQLite in the dialect box so a backslash inside quotes stays the literal character SQLite treats it as (SQLite has no backslash escapes in strings; a bare # is not valid SQLite at all and is read as a comment here). Schema statements keep their tokens: CREATE TABLE IF NOT EXISTS with AUTOINCREMENT and DEFAULT CURRENT_TIMESTAMP comes out with the same characters it went in with. Everything runs in the browser.
What picking SQLITE actually does
This formatter is one layout engine, not three parsers, and it will not rewrite your SQL into another dialect. Picking SQLITE changes one thing: how two spellings that mean opposite things in two engines get read from the text — and it moves 1 of them away from the Auto reading. Everything on this page came out of that engine at build time, in this mode, so you can paste the same input and check it line for line.
A bare # between two operands
PostgreSQL spells integer bitwise XOR with #. MySQL reads the same byte as a line comment running to end of line. No parser can tell the two apart from the text alone, so the mode you pick decides which one survives.
Typed in
SELECT a # b FROM t;
Formatted in SQLITE mode
SELECT a # b FROM t;
The same text in PostgreSQL mode
SELECT a # b FROM t;
Minified in SQLITE mode
SELECT a
Minified in PostgreSQL mode
SELECT a # b FROM t;
SQLite has neither a # comment nor a # operator, so this mode reads the line the way Auto does. On a PostgreSQL source that means the XOR was treated as a comment and its tail dropped.
A # comment above a clause
The same bytes are a comment in two of these modes and an operator in the third, and the difference is visible in where FROM t ends up.
Typed in
SELECT 1 # section FROM t;
Formatted in SQLITE mode
SELECT 1 # section FROM t;
The same text in PostgreSQL mode
SELECT 1 # section FROM t;
Minified in SQLITE mode
SELECT 1 FROM t;
Minified in PostgreSQL mode
SELECT 1 # section FROM t;
Auto and this mode agree again. There is no SQLite reading in which that # is an operator, so a query relying on it was never SQLite to begin with.
A string literal ending in a backslash
The classic Windows-path case. If a backslash escapes the next character, the first literal runs past its closing quote and fuses with the next one — and the text between the quotes starts being treated as code.
Typed in
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
Formatted in SQLITE mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
The same text in Auto (MySQL-safe) mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
The same text in MySQL / MariaDB mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
Minified in SQLITE mode
SELECT 'C:\' AS p, 'a FROM b' AS q FROM t;
Minified in Auto (MySQL-safe) mode
SELECT 'C:\' AS p, ' a FROM b ' AS q FROM t;
Minified in MySQL / MariaDB mode
SELECT 'C:\' AS p, ' a FROM b ' AS q FROM t;
SQLite performs no backslash escapes inside strings, so both literals survive exactly as written and FROM stays outside the quotes. Under the Auto reading this same input fuses into one literal.
What does not change
SQLITE constructs come through formatting and minifying with the same characters they went in with, in every mode. That is deliberate — the layout pass is engine-agnostic — but read it as "your tokens survive", never as "the tool understands SQLITE". It cannot validate anything, and broken SQL will be prettified into something that looks correct.
CREATE TABLE IF NOT EXISTSwithAUTOINCREMENTand aDEFAULT:CREATE TABLE IF NOT EXISTS audit_log (id INTEGER PRIMARY KEY AUTOINCREMENT, ts DATETIME DEFAULT CURRENT_TIMESTAMP);
- the two-argument
group_concat(x, delimiter)SQLite actually accepts:SELECT group_concat(x, ',') FROM t;
RETURNING(SQLite 3.35+):INSERT INTO t (a) VALUES (1) RETURNING id;
- window functions (SQLite 3.25+):
SELECT a, ROW_NUMBER() OVER (PARTITION BY b ORDER BY c ) rn FROM t;
One warning that applies in every mode
Minify is not a shrinker of meaning. It collapses the statement onto one line and deletes every comment style — --, # and block — so anything an audit trail or an EXPLAIN annotation relies on is gone rather than compressed.
SELECT 1 FROM t;
Frequently Asked Questions
Does minifying make my SQLite query faster?
No. Minify produces a compact single line so the statement takes less room in a migration file, a source constant, or a schema dump — nothing about the query plan changes. SQLite parses the minified and formatted forms identically. The size it saves is whitespace, and the thing it costs is your comments.
What does minify do to the comments in my migration?
It deletes them. --, # and block comments are all stripped, so a migration whose comments explain an irreversible column change loses that explanation permanently once only the minified line is committed. Minify for transport, keep the commented source in version control.
Does SQLite mode handle backslashes the way MySQL does?
No, and that is the reason to select it. SQLite performs no backslash escapes inside string literals, so a value like a Windows path ends at its own closing quote and stays a value. Auto inherits the MySQL reading, where that trailing backslash escapes the closing quote and fuses the literal with whatever follows. A bare # is not valid SQLite at all and is read as a comment here.