Minify SQL to a single line
Collapse a SQL query onto one line for a config file, an env var or a log entry. Comments optional, tokens untouched, nothing uploaded.
- Runs in your browser
- Files are never uploaded
- Free, no account
Adds ILIKE, RETURNING, ON CONFLICT, dollar-quoted bodies and :: casts.
Your SQL never leaves this tab — check it yourself—
Starting the network probe…
The counter above wraps fetch, XMLHttpRequest and navigator.sendBeacon in this tab and counts every call. It does not block anything — it just reports.
Two ways to verify independently
- Turn off Wi-Fi or enable airplane mode, then use the tool. It keeps working, because the page is already fully loaded.
- Open your browser devtools, switch to the Network tab, clear it, and run the tool. No new row appears.
Why this matters
In 2025 researchers found that popular online formatters had retained tens of thousands of user-submitted snippets — JSONFormatter.org and CodeBeautify together exposed roughly 80,000 saved documents, many containing live cloud credentials, private keys and internal database connection strings, because “format this” quietly meant “upload this”. A separate incident exposed roughly 3.5 million user PDFs on a document-conversion service. The only structural fix is not sending the data in the first place: this site is served under a Content-Security-Policy whose connect-src contains no third-party origin, so a request off this device cannot be made even by accident.
When a one-line query is the right answer
Minifying SQL is not a performance technique — the database throws your whitespace away during parsing. It is a packaging technique, and there are four places it genuinely helps.
- Config files. A multi-line query in YAML needs a block scalar and correct indentation; in JSON it needs every newline escaped as
\n. One line sidesteps both. - Environment variables. A newline inside an env var is awkward in Docker, systemd and most CI systems. One line avoids the quoting entirely.
- Log lines. Structured loggers treat a newline as a record boundary, so a multi-line query becomes six unrelated log entries and a grep finds only the fragment you searched for.
- Comparing two queries. Two functionally identical queries formatted differently look completely different. Minify both and a character-level diff shows the real change.
Comments: remove or keep?
Removing them is the default, and not only to save bytes. A line comment introduced with
-- runs to the end of the line, so if the newline disappears the comment swallows
the rest of the statement. Keeping comments therefore forces a newline after each one, which
means the output is no longer strictly one line.
Block comments are safer — /* … */ has an explicit terminator — but they still cost
bytes and rarely help a machine consumer. If the comments matter, keep the formatted version in
version control and minify only at the point of use.
What is preserved exactly
| Token type | Treatment |
|---|---|
| String literals | Byte-for-byte, including doubled quotes, backslash escapes in MySQL, and Postgres dollar-quoted bodies |
| Quoted identifiers | Byte-for-byte, with the quoting style of the selected dialect |
| Numbers, operators, parameters | Unchanged; $1, :name, @var and ? all survive |
| Keywords | Case changed only if you ask for it |
| Whitespace between tokens | Collapsed to nothing, or to one space where removing it would join two tokens |
That last row is the subtle one. a AND b cannot become aANDb, so a
single space is kept whenever the character before and the character after are both word
characters. Everywhere else — around commas, parentheses and operators — the space goes.
How much smaller?
A formatted analytics query with one column per line and a comment header typically loses 35–55% of its bytes. A hand-written single-statement query that was already compact might lose 10%. The before, after and saved-percentage figures for your own query appear above the output.
Getting it back
Minification here is lossless with respect to tokens, so pasting the result into the SQL formatter reconstructs a readable query — with the caveat that any comments you removed are gone for good. Keep the readable version as the source of truth and treat the minified form as build output.
Questions
Why would I want SQL on one line?
Three common reasons: pasting a query into a YAML or JSON config field where a newline would need escaping, putting it into an environment variable, and getting a whole statement into a single log line so a grep finds all of it. It also makes two queries easy to compare character by character.
Is minified SQL faster?
No. The database parses the statement before planning it, and whitespace is discarded at that stage. Minification only reduces the number of bytes you transmit and store — it has no effect on query time.
What happens to my comments?
Your choice. Removing them is the default because a line comment on one line swallows the rest of the statement. If you keep them, a retained line comment is followed by a newline so the query still parses — which means the output is not strictly one line.
Are string literals safe?
Yes. The tokenizer treats a quoted string as one token, including doubled quotes and dollar-quoted Postgres bodies, so a comma or a double space inside a literal is preserved exactly. Only whitespace between tokens is collapsed.