SQL Formatter

What a SQL formatter is allowed to change — and how to check

A formatter's whole contract is whitespace and keyword case, nothing else. No competing tool checks its own work — this one does. Every format and minify run tokenises the input and the output with the same hand-written lexer and walks the two streams side by side: same token count, same kinds at every position, every string, number, identifier, comment and parameter byte-identical, and keywords equal case-insensitively when a case option is applied. The Verified tab prints the result — a headline like "217 tokens in, 217 out, verified" — and if the two streams ever disagree, the output is cleared rather than shown, because a formatter that failed its own check has no result worth trusting (non-negotiable #1 of how this whole site is built). The receipt also names anything a Risky option changed, such as which unquoted identifiers had their case rewritten and on which line.

Why your SQL formatter chokes on an INSERT

Measured 2026-09-12: the sql-formatter npm package — the engine behind most free SQL formatter websites — took 2.57 seconds and 977 MB of heap to format an 8,000-row INSERT (222 KB), and crashed out of memory at 4 GB on 20,000 rows. sqlparse (the engine behind sqlformat.org) refuses a 1,000-row INSERT outright with a "maximum number of tokens exceeded" error at 10,000 tokens. Both are entirely realistic pastes — a spreadsheet export, a migration file, a chunk of a mysqldump. This tool's lexer streams the input in a single pass with no array built for a whole comma list, so a multi-megabyte dump formats without a frozen tab.

What the dialect dropdown actually changes

Picking a dialect changes lexing, never layout — a PostgreSQL query and a T-SQL query with the same clause shape are laid out identically. What differs is what a token is: MySQL and BigQuery treat "text" as a string, while PostgreSQL and SQL Server treat it as a case-sensitive identifier. PostgreSQL's '…' takes backslashes literally and needs E'…' to escape; MySQL escapes with a backslash by default. A bare -- starts a comment everywhere except MySQL, which requires a trailing space or it reads as subtraction. Block comments nest in PostgreSQL and T-SQL but not in MySQL, SQLite or Oracle. And a query parameter looks completely different per driver: `?` for JDBC/ODBC, $1 for PostgreSQL's own placeholder syntax, :name for Oracle and SQLAlchemy, @name for T-SQL variables. Getting any of these wrong is exactly how a competing formatter turns d = @p into d = @ p and breaks a real query — this tool's lexer profile decides per dialect, and never guesses.

Remove comments — except the ones that run

MySQL's /*!40101 SET NAMES utf8 */ is not a comment — it is a version-gated directive that executes on MySQL 4.01.01 and above, and every mysqldump file starts with a dozen of them. Optimizer hints (/*+ INDEX(t idx) */) work the same way in Oracle and MySQL 8. A popular Python formatter's "strip comments" option deletes both — measured, on the exact mysqldump header shown above. This tool's lexer classifies a directive as its own token kind and keeps it in every mode, including with "Remove comments" turned on, and the receipt says how many it kept and why.

Layout control most SQL formatters don't offer

Every free formatter measured for this page offers roughly the same four case switches and three indent styles — the option set the sql-formatter npm package defines, copied across a dozen sites with a different skin. This tool's Customize panel goes further: indent width (2 or 4 spaces, or a tab) and three layout styles as expected, plus leading-comma placement (pgFormatter's own option, and the one most sql-formatter-based sites don't have), which side of the line AND/OR starts on, a configurable wrap width for long expressions and comma lists (40-120 columns), and separate toggles to expand every IN (…) list and CASE expression onto its own lines — Poor SQL's option, otherwise absent from every client-side formatter in this category. None of these change what the query does; they only change how it reads, and the verification receipt applies to every combination of them the same way it applies to the defaults.

Highlighted output, and a flag for likely keyword typos

The formatted output is re-lexed with the same tokeniser that produced it — never a second regex pass that could mistake a string or a comment for a keyword — so keywords and function calls, strings, numbers, comments, directives and parameters each get their own colour, while plain table and column names stay uncoloured rather than tinting the whole query one shade. The same pass flags a narrow, specific mistake: an identifier sitting in a slot where only one keyword is legal — the start of a statement, right after GROUP or ORDER, or right after a JOIN introducer like LEFT or INNER — that's a near-miss spelling of the word that slot requires. SELECTT, GROUP BYY and INNER JOOIN get underlined in red with a "did you mean" tooltip and a matching receipt note; a table genuinely named SELECTOR is never touched, because the check only fires in a slot where a keyword is the only legal thing to write. It's a hint, never a block — formatting still runs and the output is never withheld over it.

Common use cases

• Reformatting a query pasted from a support ticket, a Slack message, or a log line
• Checking that formatting a query hasn't silently renamed a MySQL table on Linux
• Reading a minified or single-line query by beautifying it first
• Formatting a multi-megabyte dump or migration file without freezing the browser
• Counting the statements, CTEs and parameters in a query before pasting it into code