MySQL Query Beautifier

Every character you typed survives -- this pass changes layout, never content. Auto and MySQL / MariaDB share the readings MySQL means: a bare # is a line comment and backslashes inside single quotes escape the next character. The layout is engine-agnostic in every mode: backtick identifiers, LIMIT 10, 20, ON DUPLICATE KEY UPDATE and GROUP_CONCAT(x SEPARATOR ...) keep their shape through formatting and minifying, and the JSONB-looking operators #>, #>> and #- stay recognised so pasted Postgres casts never truncate your query. Minify deletes comments instead of compressing them.

SQL Query Formatter MYSQL / MARIADB

UPPERCASE

Raw SQL

0 chars

Formatted SQL

Instant formatting

What picking MYSQL / MARIADB actually does

Auto and MYSQL / MARIADB produce byte-identical output on every probe below, so picking MYSQL / MARIADB does not change how this formatter reads your query — Auto already guesses the way MySQL does. The box still matters for the queries it guesses about: two spellings mean opposite things in two engines, and a formatter that cannot ask has to pick one. Those are the cases here, shown from this mode and from the modes that read them differently.

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 MYSQL / MARIADB mode

SELECT a
# b FROM t;

The same text in PostgreSQL mode

SELECT a # b
FROM t;

Minified in MYSQL / MARIADB mode

SELECT a

Minified in PostgreSQL mode

SELECT a # b FROM t;

This mode reads # as a line comment, which is correct MySQL and what Auto inherits. If the query was written for PostgreSQL, that # was XOR and everything after it on the line has just been deleted.

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 MYSQL / MARIADB mode

SELECT 1
# section
FROM t;

The same text in PostgreSQL mode

SELECT 1 # section
FROM t;

Minified in MYSQL / MARIADB mode

SELECT 1 FROM t;

Minified in PostgreSQL mode

SELECT 1 # section FROM t;

Auto and this mode agree: the # run is lifted onto its own line as a comment. Minify then removes it outright, so an annotation an audit trail relies on does not survive minification.

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 MYSQL / MARIADB mode

SELECT 'C:\' AS p, 'a
FROM b' AS q FROM t;

The same text in PostgreSQL mode

SELECT 'C:\' AS p,
  'a FROM b' AS q
FROM t;

The same text in SQLite 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;

Minified in PostgreSQL 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;

MySQL honours backslash escapes inside string literals, so this mode follows Auto: the trailing backslash escapes the closing quote, the two literals fuse, and the text between them is reflowed as if it were code. Correct for MySQL, destructive for PostgreSQL.

What does not change

MYSQL / MARIADB 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 MYSQL / MARIADB". It cannot validate anything, and broken SQL will be prettified into something that looks correct.

backtick identifiers:
```
SELECT `order`
FROM `t`;
```
the two-argument LIMIT offset, count:
```
SELECT *
FROM t
LIMIT 10,
  20;
```

GROUP_CONCAT with SEPARATOR:

SELECT GROUP_CONCAT(x SEPARATOR ',')
FROM t;

ON DUPLICATE KEY UPDATE:

INSERT INTO t (a)
VALUES (1) ON DUPLICATE KEY
UPDATE a = a+1;

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;

More from SQLFormat

SQL Formatter & Beautifier Paste a query to indent it, uppercase its keywords, or minify it to one line. Main tool SQL Query Analyzer Paste SQL for a quick heuristic check: UPDATE or DELETE without WHERE, SELECT *, implicit cross joins,… Tool PostgreSQL Query Formatter & Beautifier Every character you typed survives -- this pass changes layout, never content. Preset SQLite Query Minifier & Single-Line Formatter Minify collapses a statement onto one line and deletes every comment style -- --, # and block comments --… Preset

Guides

SQL Formatting Best Practices SQL Patterns and Gotchas Postgres Migration Safety Reading Postgres Query Plans SQL Minification Deletes Your Comments ORM-Generated SQL Gotchas

All tools →All 13 guides →

Frequently Asked Questions

Is there any difference between Auto and MySQL mode?

Not in output. Auto already guesses the way MySQL does, so on every probe this site runs the two modes produce byte-identical text — selecting MySQL changes nothing about how your query is read. The box still matters for queries Auto guesses about: the ambiguous spellings it resolves are MySQL readings, so a query written for another engine can be quietly reinterpreted while looking untouched.

What happens to my # comments when I minify?

They are deleted, not compressed. Minify removes every comment style — --, # and block — and collapses the statement onto one line. An annotation an audit trail or an approval process depends on does not survive the round trip, so keep the commented source and treat the minified line as a disposable copy.

Are backticks, LIMIT 10, 20 and ON DUPLICATE KEY UPDATE preserved?

Yes — MySQL-specific syntax keeps the same characters it went in with, in formatting and in minifying, in all four modes. Read that as "your tokens survive", never as "the tool understands MySQL": there is no parser behind it, so a query with a missing comma or an unbalanced quote will come out looking tidy and still be wrong.

🧭 Pro Tips & Gotchas

<!-- Per-route Pro Tips for /sql/mysql-beautifier/. Does not repeat

content/sqlformat.md (see the postgres-formatter file's note for why). Every

bullet verified against apps/sqlformat/src/core.js. -->

Start here: Auto already is this mode

Formatting and minifying in Auto and MySQL / MariaDB give byte-identical text on every probe this site runs. Selecting MySQL changes nothing about how your query is read. The dialect box matters only for queries that contain a spelling Auto has to guess at — and the guesses it makes are the MySQL ones, which is why a query written for PostgreSQL can be reinterpreted while looking completely unchanged on screen.

MySQL readings this mode applies

A bare # starts a line comment. SELECT a # b FROM t keeps a, and b FROM t rides along as a comment — then minify deletes it outright. That is correct MySQL and the reason a pasted Postgres query silently loses its tail here.
A backslash inside single quotes escapes the next character. A Windows path stored as 'C:\' runs past its closing quote and fuses with the following literal; the text between them is then reflowed as if it were code.
Backtick-quoted identifiers survive both passes, and quoting also protects a word from the uppercase toggle: ` SELECT order ` stays lowercase while the unquoted version is rewritten to the keyword.
Two-argument LIMIT 10, 20 keeps its order and its comma. ON DUPLICATE KEY UPDATE survives intact, though a=a+1 is respaced to a = a + 1.

Two MySQL habits this pass will not fix for you

GROUP_CONCAT(x SEPARATOR ',') keeps the separator exactly as typed, but the construct is MySQL-only — the same argument shape in SQLite is the two-argument group_concat(x, ','), and pasting one into the other engine is a syntax error, not a formatting problem. IFNULL versus COALESCE, STRAIGHT_JOIN, and GROUP BY implicit ordering are the same kind of portability trap and nothing here warns you. See the [dialect differences guide](/guides/postgres-vs-mysql-dialects/) for the spellings that mean opposite things in the two engines.