SQL Formatter

Pastes in as a single unreadable line, comes out with clauses on their own lines, columns broken out, and AND/OR conditions indented under WHERE — the difference between a query you can actually review in a PR and one you're squinting at trying to find the missing JOIN condition.

This is a formatter, not a parser

Worth being upfront about: this works by recognising SQL keywords (SELECT, FROM, WHERE, JOIN, GROUP BY, and so on) and restructuring the text around them — it doesn't actually understand SQL semantics, validate syntax, or know whether your query would run. That's genuinely how most SQL formatting tools work, online or in an IDE plugin, and it's a deliberate tradeoff: a full SQL parser has to understand every dialect's quirks (MySQL vs Postgres vs SQL Server vs Snowflake all differ), while a keyword-based formatter works reasonably well across all of them at the cost of not catching an actual syntax error.

What it handles correctly

String literals are protected before any keyword matching happens — so a column value like 'SELECT this literally' doesn't get mistaken for a clause and mangled
Multi-word join types (LEFT OUTER JOIN, INNER JOIN) are matched as whole phrases, not split apart by a shorter keyword match on just JOIN
Column lists after SELECT, and value lists after SET, get split one-per-line at the top level — but not inside a function call's parentheses, so COUNT(a, b) stays together instead of being broken across lines
AND / OR get indented under whichever clause they're extending, so a long WHERE clause reads as a list of conditions instead of a wall of text

Why this is worth doing before a query review, not just for looks

A badly-formatted query hides logic errors — a misplaced AND versus OR, a JOIN condition that's actually a Cartesian product because the ON clause is wrong, a WHERE clause that only looks like it's filtering what you think it's filtering. Reformatting a query doesn't fix any of that, but it makes those mistakes visible instead of buried in a 200-character single line, which is often the difference between catching a bug in review and catching it in production after it's already returned wrong data to someone.