SQL Formatter

Common questions

Will it change anything inside my strings?

No, by construction. The formatter works on a token stream, and everything between quotes is a single opaque token it can only copy. A WHERE value containing the word 'select' can never be mistaken for a clause, and doubled-quote escapes like 'it''s' survive exactly.

How are subqueries laid out?

Each subquery nests one level past the line that opened it, and its closing parenthesis comes back to that line's own indent, so a subquery inside AND id IN ( closes under the AND, and a subquery inside it nests a level deeper still. Function calls like count(*) stay inline; only parentheses that open a SELECT get the block treatment.

Should SQL keywords be uppercase?

It is convention, not syntax. SQL is case-insensitive about keywords. Uppercase makes the query's skeleton stand out from table and column names, which is why most style guides still ask for it. All three options are here: UPPER, lower, or leave them exactly as typed.

Which SQL dialects does it handle?

The formatting rules are dialect-neutral and cover the shared core: standard quoted identifiers, MySQL backticks, SQL Server brackets, PostgreSQL casts like id::text, and parameter styles :name, @var and $1 all tokenize correctly. It formats structure rather than validating grammar, so dialect-specific clauses pass through on their own lines.

Are my comments kept?

Yes, both -- line comments and /* block */ comments are preserved in place. The Minify action is the one exception: it strips comments deliberately, because its job is producing the shortest single-line version for embedding in code or logs.

Is my SQL sent to a server?

No. Formatting runs entirely in your browser, which matters for SQL more than most things people paste into online tools. Queries carry table names, business logic and sometimes literal customer data. Nothing is uploaded, logged or stored.