Backtick identifiers
MySQL commonly uses backticks around identifiers, including reserved words and names with special characters. Each component of a qualified name is quoted separately, as in `sales`.`order`.
MySQL is selected by default
Paste a MySQL query and control its layout
The formatting engine runs in an isolated browser worker. It can improve presentation while retaining MySQL-oriented token rules, but it does not connect to a server or certify the statement.
Loading the private MySQL formatter…
Enable JavaScript to format MySQL locally. The SQL mode, comment, JSON, privacy, and validation guidance below remains readable without it.
A focused three-step workflow
How to format MySQL online
Keep the dialect explicit, choose presentation rules, and verify correctness separately.
- 1
Paste recoverable MySQL
Start from version-controlled or otherwise recoverable SQL. This page opens with the MySQL dialect selected, so backticks, MySQL keywords, comments, operators, and clauses receive the matching formatter profile.
- 2
Choose a readable style
Set spaces or tabs, keyword case, expression width, logical-operator line breaks, statement spacing, compact operators, and semicolon placement. These are layout choices rather than server settings.
- 3
Format, diff, and test
Compare the output with the original. Then parse, prepare, explain, and test through the exact MySQL version, session SQL mode, schema, credentials, and application path that matter.
Why generic SQL is not enough
What makes MySQL formatting dialect-specific?
MySQL shares core SQL clauses with other databases, but important tokens and modes differ at the edges.
SQL modes
ANSI_QUOTES, NO_BACKSLASH_ESCAPES, IGNORE_SPACE, and other modes can affect syntax or validation. A formatter has no access to the current session mode.
Comments and hints
#, whitespace-sensitive -- , block comments, executable /*! ... */ forms, and /*+ ... */ hints must not be treated as interchangeable decoration.
MySQL clauses and functions
LIMIT, question-mark parameters, JSON functions and operators, ON DUPLICATE KEY UPDATE, and other extensions need a MySQL-aware vocabulary and layout.
Preserve tokens before changing whitespace
Backticks, strings, and MySQL SQL modes
Backticks delimit MySQL identifiers. They can protect a reserved word such as `order` or retain characters that are not permitted in a plain identifier. For a qualified object, quote the components independently: `analytics-prod`.`orders` is a database identifier, a separator, and a table identifier, whereas one quoted string containing the dot would name a different object. Formatting should retain both the quote marks and the exact identifier text.
Quote interpretation can depend on sql_mode. With ANSI_QUOTES, double quotes delimit identifiers and cannot delimit string literals. With NO_BACKSLASH_ESCAPES, the backslash is an ordinary character in strings instead of introducing MySQL escape sequences. IGNORE_SPACE changes how certain built-in function names followed by whitespace are parsed and makes affected names reserved. A local formatter cannot discover the global or session value of these modes.
For that reason, the formatter should not convert one quote style to another or claim that successful tokenization proves server acceptance. Select MySQL, preserve original literals and identifiers, and validate under the same SQL mode as the application connection. The official MySQL 8.4 SQL mode reference explains which modes affect supported syntax and data checks.
`name`- The usual MySQL form for a delimited identifier.
ANSI_QUOTES- Makes double quotes identifier quotes rather than string quotes.
NO_BACKSLASH_ESCAPES- Disables special backslash escape handling in strings.
IGNORE_SPACE- Changes whitespace-sensitive built-in function name parsing.
Some comments can affect execution
Preserve MySQL comments and optimizer hints
Comment placement is part of a trustworthy formatting diff.
FormMySQL meaningFormatting rule
# commentA MySQL line comment through the end of the line.Keep its text and line association.-- commentA line comment only when the second dash is followed by whitespace or a control character.Do not remove the required separator./* comment */A block comment; nested block comments are not supported for ordinary use.Retain delimiters, contents, and position./*! code */A MySQL extension comment whose contents may be parsed and executed by MySQL.Never discard it as decorative text./*+ hint */An optimizer-hint comment tied to a statement or query block.Keep it attached to the intended structure.A generic pretty printer may see all block comments as equivalent whitespace. MySQL does not. Version-qualified executable comments can gate syntax by server version, and optimizer hints can influence plans. The MySQL profile aims to preserve these tokens, but you should still compare the original and formatted query and consult the official MySQL 8.4 comment syntax.
Common MySQL query details
LIMIT, placeholders, and JSON functions
MySQL accepts familiar row-limit forms including LIMIT row_count, LIMIT offset, row_count, and LIMIT row_count OFFSET offset. The comma form deliberately places the offset first, while the OFFSET form places the row count first. A formatter should make the chosen form readable without swapping numbers or translating it into SQL Server TOP or another dialect.
A question mark is the parameter marker in MySQL prepared statements. Named placeholders such as :status can be conventions implemented by a connector, query builder, or template system before the server sees SQL. Formatting should preserve either form exactly; it does not bind values or make string concatenation safe. Use the connector's parameter API and review the compiled query where templates are involved.
MySQL JSON functions and operators combine SQL syntax with JSON path strings. Functions include JSON_EXTRACT, JSON_SET, JSON_OBJECT, and JSON_TABLE; the -> and ->> operators provide extraction forms in supported contexts. A formatter may wrap the surrounding expression, but it must not rewrite a quoted path such as '$.customer.id' or assume the path is an identifier.
Formatting is not translation
Changing LIMIT, placeholder conventions, JSON functions, identifier quotes, or upsert syntax for another database would be a semantic conversion. This page keeps MySQL selected and changes presentation only.
SELECT /*+ BKA(o) */
o.`order`,
JSON_UNQUOTE(JSON_EXTRACT(o.payload, '$.customer.id')) AS customer_id,
JSON_LENGTH(o.payload -> '$.items') AS item_count
FROM `sales`.`orders` AS o
WHERE o.status = ?
AND o.created_at >= ?
ORDER BY o.created_at DESC
LIMIT 50 OFFSET 100;Query text stays in the current browser tab
Private MySQL formatting with a local worker
MySQL queries can expose database and table names, tenant filters, internal JSON paths, incident evidence, migration plans, and product logic even when no result rows are present. LiveParse does not send the query to a formatter API. Pressing format starts a Web Worker created by this page; the worker returns the formatted text only to this tab.
Input is limited to exactly 50,000 characters, and the worker is terminated when a formatting run exceeds exactly 2 seconds. These boundaries protect browser responsiveness. Beginning another run terminates the previous worker so an older result cannot replace newer work. The page does not connect to MySQL, place the query in the URL, or store it in browser storage.
Local processing cannot control browser extensions, clipboard history, downloaded files, screen sharing, device backups, or other software on the machine. Remove credentials and unnecessary production values, and follow your organization's data-handling policy. LiveParse's separate, limited search-referral measurement is described on the privacy page.
No MySQL connection
The formatter has no hostname, port, credentials, schema catalog, session SQL mode, character set, collation, permissions, transaction, or server version. It cannot run or approve a statement.
Return to the formatter →Readable is not correct
MySQL formatting is not validation or execution
Syntax depends on context
The exact MySQL release, SQL mode, character set, stored-program context, and client preprocessing can affect parsing. A formatter's dialect profile cannot reproduce every server and session condition.
Names and types need a catalog
A polished query can reference a missing table, misspell a column, compare incompatible values, or call a function unavailable on the target server. LiveParse has no schema metadata.
Permissions and safety are separate
Formatting does not detect an overprivileged account, missing tenant predicate, destructive update, injection boundary, unintended lock, or excessive scan. Apply least privilege and review.
Results need tests
A statement may parse and execute while returning the wrong rows or changing the wrong records. Use prepared parameters, transactions where appropriate, representative fixtures, assertions, and application tests.
After formatting, inspect a token-aware diff. Validate or prepare the statement through the target MySQL environment, use EXPLAIN where appropriate, and execute only with the permissions and isolation intended for that query. Do not use “formatted successfully” as a deployment or security decision.
Use the execution target, not visual similarity
Need a different SQL formatter?
Backticks and familiar clauses do not prove that a query is MySQL.
General SQL Formatter
Choose from the full dialect list and configure indentation, keyword case, expression width, operators, and statement spacing.
PostgreSQL SQL Formatter
Format PostgreSQL double-quoted identifiers, dollar-quoted strings, casts, JSON operators, filters, and window expressions.
BigQuery SQL Formatter
Format GoogleSQL backtick paths, arrays, structs, UNNEST, query parameters, windows, and QUALIFY.
SQL Server Formatter
Format T-SQL bracketed identifiers, variables, TOP, common table expressions, and OFFSET … FETCH.
Read the MySQL, PostgreSQL, BigQuery, and SQL Server formatting guide →
Questions answered
MySQL formatter FAQ
Does the MySQL formatter upload or execute my query?
No. Formatting runs in a Web Worker in the current browser tab. LiveParse does not send the query to a formatting API, connect to MySQL, put the SQL in the URL, or store it in browser storage.
Does formatting prove that MySQL will accept the query?
No. Formatting changes layout. It does not validate the exact MySQL version, SQL mode, schema, data types, functions, privileges, query plan, returned rows, side effects, or security. Check the statement through the real target and application tests.
Does the formatter preserve MySQL backtick identifiers?
The MySQL dialect profile recognizes backtick-delimited identifiers and keeps their spelling and quoting. It does not convert them to strings or another database's identifier style. Review the result whenever SQL mode or generated syntax changes token meaning.
What happens to MySQL comments and optimizer hints?
The formatter is designed to preserve # and valid double-dash line comments, block comments, executable version comments, and optimizer hints. Always inspect their placement because /*! ... */ and /*+ ... */ forms can affect execution.
Can it format LIMIT, placeholders, and MySQL JSON functions?
Yes. The MySQL profile recognizes common LIMIT forms, question-mark placeholders, JSON functions, extraction operators, and quoted JSON paths. Formatting preserves these tokens; it does not bind parameters, validate paths, or translate syntax.
Can it format stored procedures or DELIMITER scripts?
No. Stored procedures and custom-delimiter scripts that use the MySQL DELIMITER client directive are not supported. Use stored-program and client-aware tooling instead, and keep the original script unchanged.
How large can a MySQL query be?
Input is limited to 50,000 characters. The formatting worker is stopped if a run exceeds 2 seconds so the page remains responsive. Split unusually large generated scripts only at statement or batch boundaries you have verified.
Does changing keyword case alter identifiers or JSON paths?
The option targets recognized SQL keywords. Identifiers, quoted text, function names, data types, and JSON paths are configured to preserve their spelling. A formatter can lag new MySQL syntax, so a diff and target-server check are still required.
Can I use this to migrate MySQL to PostgreSQL or SQL Server?
No. Formatting is not dialect translation. A migration must address types, functions, quoting, pagination, JSON behavior, upserts, stored programs, indexes, transactions, collations, and application semantics with dedicated tooling and tests.