SQL Formatter & Beautifier

🧭 Pro Tips & Gotchas

What the formatter actually does

• It is keyword-anchored, not a SQL parser: recognised clauses (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, AND/OR) get their own line and indent level.
• Uppercase toggle rewrites keywords by word-boundary matching, so order_id is left alone while a bare order is treated as the ORDER keyword.
• Indent size is applied per nesting level, which is what makes subqueries readable — and what makes deeply nested CTEs drift off-screen.

Gotchas

• Strings and quoted identifiers are protected. A literal containing from ('select * from users') stays on one line, and so do commas, semicolons, parens and quotes inside it — the tokenizer reads the whole literal as one token before any layout happens. Tested against 8 literal shapes; none were split.
• What is not protected is your whitespace inside a literal: a literal containing a newline keeps it, so a multi-line string still multi-line-breaks the output visually even though nothing was lost.
• UPPERCASE rewrites any word that happens to be a keyword, including one you used as an identifier: SELECT order FROM orders AS order comes back as SELECT ORDER ... AS ORDER. Quote it ("order", ` order `) to protect it, or leave the toggle off — with the toggle off, your original casing is reproduced exactly.
• A window definition gets reflowed as if it were query structure: inside OVER (...), ORDER BY breaks onto its own line at the outer indent and the closing paren lands at column 0. Nothing is lost, but the window clause no longer reads as one unit. Check OVER (...) after formatting.
• Dialect extensions get layout, not understanding. RETURNING breaks onto its own line and a LATERAL subquery indents, because both are matched as keywords — not because the formatter knows PostgreSQL. QUALIFY stays glued to the line it is on, and BigQuery's SELECT * EXCEPT (...) is read as a set-operation EXCEPT, so it breaks where a BigQuery reader would not expect. Nothing errors; that is the trade.
• Minify deletes comments. -- note, # note and / note / are all removed, not compressed. Anything an audit trail depends on is gone after a minify pass, in every engine's comment style.
• The dialect select changes exactly two readings, not the layout. The formatting pass is identical in every mode; the select decides how a bare # is read (MySQL line comment vs PostgreSQL integer XOR — Auto and MySQL trim everything after it, PostgreSQL keeps flags # 4 as a predicate) and whether a backslash inside single quotes escapes the next character (MySQL) or stays a literal character (PostgreSQL with standard_conforming_strings=on, and SQLite — where 'C:\' genuinely means C:\). Past a string ending in a backslash, the wrong mode can fuse two literals or split one across lines — so if your SQL contains either spelling, pick your engine.
• Do not minify nested block comments (/ a / b / c /). No engine supports nesting, the tokenizer stops at the first /, and the remainder gets reassembled as operators. The same applies to an unterminated /, which swallows the rest of the statement.
• Comments survive positionally, not semantically — a trailing -- note can end up leading the next clause after reflow.
• Because there is no parser, the formatter cannot validate. It will happily prettify syntactically broken SQL and make it look correct, which is worse than ugly broken SQL.
• For anything machine-generated, prefer a real formatter (sqlglot, sqlfmt, pg-formatter) and keep this for interactive scratch work.