T-SQL / SQL Server formatting
Pick the T-SQL dialect and three things change. [Bracketed identifiers] are recognized as single tokens, so [Order Details] never gets split or re-cased. GO is treated as what it is — a batch separator, not a statement — so it stays on its own line with a blank line around it, and formatting state resets per batch, exactly how script files with multiple batches should read. And TOP stays glued to its SELECT instead of being wrapped like a column. Everything else T-SQL shares with standard SQL — JOIN layout, CASE indentation, comma style — behaves identically. If your script mixes DDL batches (CREATE PROCEDURE … GO) with queries, paste the whole thing; each batch formats independently.
PostgreSQL formatting
The PostgreSQL dialect adds recognition of dollar-quoted strings — $$…$$ and tagged forms like $body$…$body$ — which is what makes function bodies safe to format: everything inside the dollar quotes passes through byte-for-byte, so a CREATE FUNCTION wrapper can be reindented without the formatter chewing on the procedural body inside. The :: cast operator is kept tight (total::numeric, never total :: numeric), "quoted identifiers" keep their case, and LIMIT/OFFSET land on their own lines like the clause keywords they are.
MySQL formatting
MySQL mode recognizes backtick identifiers (`order` — commonly needed because MySQL schemas are full of reserved-word column names) and the # line comment, which only MySQL treats as a comment. Both survive formatting untouched. LIMIT gets clause treatment, and backslash escapes inside strings ('it\'s') are tokenized correctly rather than ending the string early — a classic way naive formatters mangle MySQL.
Formatting style: the choices and what they're for
| Option | Choices | The argument |
|---|---|---|
| Keyword case | UPPER / lower / as typed | UPPERCASE keywords are the traditional way to make structure pop in monochrome editors; lowercase reads quieter in syntax-highlighted ones. Neither affects execution anywhere. |
| Comma style | trailing / leading | Trailing is what most style guides print. Leading commas exist because commenting out or reordering the last select-list item never breaks the query, and column diffs touch one line. Both are correct SQL; this is the DBA religion toggle — pick your congregation. |
| Indent width | 2 / 4 / 8 / tab | 4 spaces is the common default for SQL; 8 mimics old server tooling; tab defers to the reader's editor. |
| Inline short queries | on / off | A 40-character query exploded across six lines is noise. When on, statements that fit in 72 characters stay on one line. |
Minify mode
The inverse job: collapse a formatted query to one line for a log message, a query-string parameter, or a migration file where diffs don't matter. Minify preserves string and identifier contents exactly, keeps required single spaces between words, and removes the rest. With "keep comments" on, block comments ride along inline; a -- line comment forces a line break after it (that's what makes it a line comment), so fully single-line output needs either block comments or comments stripped.
Frequently asked questions
Does my query get uploaded anywhere?
No. The tokenizer and formatter are JavaScript written into this page — there's no server round-trip and no third-party library fetched at runtime. Open your browser's DevTools Network tab, paste your gnarliest production query, and watch: no request leaves. The page also keeps working with the connection off. For queries that embed schema details and business logic, that's the whole reason to prefer a client-side formatter.
What are the differences between the dialects here?
The dialect setting changes how text is tokenized, which is where formatters break queries: T-SQL adds [bracket] identifiers and GO batches; MySQL adds `backticks`, # comments, and backslash string escapes; PostgreSQL adds $$dollar-quoted$$ strings and tight :: casts; PL/SQL follows standard quoting. What it deliberately doesn't do is validate your SQL against a dialect's grammar or translate between dialects — a T-SQL query formatted under the MySQL setting is still T-SQL, just possibly mis-tokenized, so pick the dialect that matches the query.
Are my comments kept?
Yes, by default — both -- line comments and /* block */ comments are preserved and stay attached to the code they annotated: a comment that shared a line with code stays on that line; a comment on its own line keeps its own line at the current indent. Uncheck "keep comments" to strip them (useful before sharing a query publicly, since comments are where credentials and internal notes hide).
What happens if my SQL has an error?
It still formats. The engine flags what it can detect — an unclosed string, an unterminated block comment, unbalanced parentheses — with the line number where the problem starts, then formats the rest on a best-effort basis instead of refusing. It won't catch semantic errors (a misspelled column name is valid SQL to a formatter); that's the database's job.
SQL Server, T-SQL, MySQL, PostgreSQL, PL/SQL, and Oracle are trademarks of their respective owners; the names are used here only to identify dialect compatibility.