SQL Formatter

Your boss wants the SQL query formatted nicely before tomorrow's review. The query came out of a Slack message as one 800-character line, and the indentation conventions of whoever wrote it originally are nowhere to be found. Manually formatting nested CTEs and JOINs is the kind of work that nobody enjoys and most editors handle poorly.

Paste the query in. The formatter normalizes keyword case, breaks SELECT lists onto separate lines, indents subqueries and CTEs, and aligns JOIN clauses so the relationships in the query become visually obvious. It handles standard SQL plus the common dialect quirks (Postgres double-quoted identifiers, MySQL backticks, SQL Server bracket syntax). The output is reformatted but semantically identical — running it produces the same result.

The formatter tokenizes the query, identifies clause boundaries (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, etc.), and rebuilds the query with consistent indentation and line breaks. Keyword case can be uppercased, lowercased, or preserved. Identifier quoting is preserved — a column wrapped in backticks stays in backticks because removing them might change the meaning. Comments are passed through unchanged. The formatter knows about CTEs (WITH clauses), window functions (OVER), and common subquery patterns; it's reasonably good at nested SELECTs and reasonably bad at heavy procedural code (PL/pgSQL, T-SQL stored procedures with control flow).

A worked example: paste in a one-line query like `select u.id,u.name,count(o.id) from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by count(o.id) desc limit 10`. The formatter produces a multi-line version with each SELECT column on its own line, the JOIN clause aligned, and the GROUP BY and ORDER BY each on their own lines with proper indentation. The same query becomes immediately scannable: you can see at a glance what's being selected, what's being joined, and what's being grouped.

Where automated formatting falls short: comments interleaved with code can end up in awkward places. Heavy stored-procedure logic with cursors, IF blocks, and exception handlers needs dialect-specific knowledge the formatter doesn't always have. Database-specific syntax like Oracle's hint comments (/*+ INDEX */), Postgres's array operators, and MySQL's index hints get passed through but may not be indented consistently. For one-off queries the formatter is fine; for production migrations, run the formatted output through your test suite or `EXPLAIN` it to confirm no semantic change. Most teams adopt a formatter and a style guide together so reviewers stop bikeshedding indentation and focus on logic.