MySQL SQL Formatter
Recognize backtick identifiers, MySQL keywords, JSON functions, executable comments, and LIMIT without treating the query as generic text.
15 dialects · Browser-only · No sign-up
Turn compressed or inconsistent SQL into a readable query with explicit dialect, indentation, keyword-case, operator, and statement-spacing controls. Your SQL stays in this tab and is never executed.
SELECT
customer_id,
SUM(total) AS revenue
FROM orders
WHERE status = 'paid'
GROUP BY customer_id;
Readable layoutDialect-aware, not executed
Format queries locally
The formatting engine runs in an isolated browser worker. It can make a query easier to read and review, but it does not connect to a database or certify that the statement is valid.
Loading the private SQL formatter…
Enable JavaScript to format SQL locally. The dialect guide and examples below remain readable without it.
A deliberate three-step workflow
Readable output begins with the dialect that will actually execute the statement.
Choose Standard SQL, MySQL, PostgreSQL, SQLite, SQL Server, BigQuery, Snowflake, Redshift, Oracle PL/SQL, DuckDB, ClickHouse, Spark, Trino, DB2, or MariaDB. The selection controls token and keyword recognition.
Set spaces or tabs, keyword case, expression width, logical-operator line breaks, blank lines between statements, compact operators, and semicolon placement.
Copy or download the result, compare it with the original, then use the target database's own parser, tests, and review process. A clean layout is not an execution approval.
Pretty-print without translation
A SQL formatter—also called a SQL beautifier, query formatter, or SQL pretty printer—rewrites whitespace and the presentation of recognized tokens so a query is easier to scan. It can place major clauses on separate lines, indent nested expressions, normalize recognized keyword case, and separate multiple statements. Formatting should preserve the query's literals, identifiers, comments, parameters, clauses, and logical order.
SQL formatting is not the same as translating between database products. Replacing MySQL LIMIT with SQL Server TOP, changing PostgreSQL operators, or rewriting BigQuery arrays would be a semantic conversion. This tool does not attempt that. It applies the selected dialect's layout rules while leaving the query in that dialect.
It is also not a database parser with a live catalog. A formatter can make an unknown table, misspelled column, incompatible function, dangerous update, or wrong join look polished. Review every meaningful token, especially after formatting generated SQL, template output, or a feature introduced by a recent database release. Stored procedures and custom-delimiter scripts, including MySQL DELIMITER directives, are not supported.
One family, many grammars
Quote characters, literals, operators, row limits, procedural blocks, and vendor clauses are not interchangeable.
Recognize backtick identifiers, MySQL keywords, JSON functions, executable comments, and LIMIT without treating the query as generic text.
Preserve double-quoted identifiers, dollar-quoted strings, casts, JSON operators, filters, window expressions, and PostgreSQL extensions.
Format GoogleSQL with backtick table paths, arrays, structs, UNNEST, named parameters, window functions, and QUALIFY.
Lay out T-SQL with bracketed identifiers, variables, TOP, common table expressions, window functions, and offset pagination.
Profiles for Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL, and Trino help retain warehouse-specific vocabulary and operators.
Standard SQL, SQLite, MariaDB, DB2, and Oracle PL/SQL profiles cover common application and enterprise query formats.
Sensitive query text stays local
Queries can reveal table names, business logic, tenant identifiers, security filters, incident details, and product strategy even when they contain no rows. LiveParse sends no query to a formatting API. When you press the format button, a worker created by this page performs the calculation locally and returns only to the page in the same tab.
The input is capped at 50,000 characters, the page warns above 25,000, formatting is stopped after 2 seconds, and excessively large output is discarded. Starting a new run terminates the previous worker so a slow query cannot overwrite a newer result. The page does not place SQL in the URL or browser storage. Copy and download occur only when you choose them.
This boundary does not control your clipboard manager, downloaded files, browser extensions, screen sharing, device backups, or other software. Remove secrets where possible and follow your organization's handling rules. Read the privacy explanation for the site's limited search-referral measurement.
LiveParse has no database hostname, credentials, schema catalog, session settings, or permission context. It cannot run SELECT, INSERT, UPDATE, DELETE, DDL, or procedural code.
Readable without pretending there is one style
Uppercase, lowercase, or preserve recognized SQL keywords. Function names, data types, identifiers, quoted text, and user-defined names retain their spelling to reduce accidental changes.
Choose two spaces, four spaces, or tabs. Indentation exposes nested subqueries, joins, common table expressions, lists, and parenthesized conditions.
A narrower width expands complex expressions sooner; a wider width keeps small expressions together. It is a readability preference, not a server limit.
Control blank lines between multiple queries and semicolon placement. Semicolons inside recognized strings and comments remain part of their token.
Formatting is one review stage
Questions answered
No. Formatting runs in a Web Worker in the current browser tab. LiveParse does not send the SQL to a formatter API or database, put it in the URL, or save it in browser storage.
No. A formatter changes layout and recognizes tokens for a selected dialect. It does not verify schemas, permissions, data types, engine versions, query plans, returned rows, side effects, or security. Validate with the exact target system.
Choose the database product and version that will execute the query. MySQL, PostgreSQL, BigQuery, SQL Server, SQLite, Snowflake, and other systems share core syntax but differ at important edges. Do not infer the dialect only from one quote character or keyword.
Yes, for ordinary semicolon-delimited statements. The formatter lets you choose one, two, or three blank lines between them. Stored procedures and custom-delimiter scripts, including MySQL DELIMITER directives, are not supported; use engine- and client-aware tooling for those inputs.
The option applies to recognized SQL keywords. Function names, data types, identifiers, strings, and user-defined names are configured to preserve their original spelling. Always review the result because dialect extensions can be newer than a formatter.
Whitespace and keyword case normally do not change a database plan, but comments, hints, string contents, batch separators, and tokens can matter. The tool aims to preserve them; you still need a diff, the target parser, and query-plan or application tests where performance matters.
Input is limited to 50,000 characters and a warning appears above 25,000. The formatting worker is stopped after 2 seconds, and output beyond 200,000 characters is discarded. These limits protect page responsiveness; split very large generated scripts at safe statement boundaries.
No. This page focuses on readable formatting. Dense operator spacing is only one presentation control. It does not promise minimum-size output and does not translate statements between database products.