SQL Formatter & Beautifier

A SQL formatter has one job that sounds trivial and is not: rearrange whitespace and keyword casing without ever changing what the query does. SQL was first standardized by ANSI in 1986 and by ISO in 1987, and it has been revised many times since — SQL-89, the large SQL-92 revision, SQL:1999 (which added recursive queries and the WITH clause for common table expressions), SQL:2003 (window functions), and SQL:2016 (JSON operators). Across all nine of those revisions the standard says nothing about layout, so every query arrives formatted however its author left it. The naive way to reformat it — run a handful of global search-and-replace patterns over the whole string — breaks on the first query that contains a string literal or a comment, because a blind regex cannot tell the difference between the keyword FROM in the query and the word from inside 'shipped from warehouse 3'. This formatter takes the correct approach instead: it tokenizes the input first, then formats only the parts that are actually code.

The layout follows the vertical style most database teams settle on. Major clause keywords — SELECT, FROM, WHERE, the six JOIN variants (INNER, LEFT, RIGHT, FULL, CROSS, and plain JOIN), GROUP BY, ORDER BY, HAVING, LIMIT, and data-modification starters like INSERT INTO and UPDATE — each begin a new line, so the shape of the statement is visible at a glance. Multi-word starters are matched longest-first, so LEFT OUTER JOIN is recognized as one clause rather than three separate words. Columns after SELECT are indented two spaces, one per line, so a diff that adds a column touches exactly one line. The boolean connectors AND and OR drop to their own indented line under the WHERE, which makes a dangling connector or an unintended condition easy to spot in review. Keyword casing is a toggle: uppercasing the roughly 60 reserved words this tool knows while keeping identifiers lowercase is the convention followed in the PostgreSQL and MySQL style guides, because it lets the eye separate fixed grammar from your own table and column names — but you can turn it off with one click.

First, this is a formatter, not a parser or a validator — it does not build a syntax tree, so it will not catch a missing comma, an unbalanced parenthesis, or a misspelled column, and it does not encode the full grammar of any one of the five major dialects: MySQL, PostgreSQL, SQLite, Microsoft SQL Server, and Oracle Database. It normalizes layout; it does not judge correctness. Second, deeply nested subqueries and common table expressions are laid out with the same clause rules rather than fully recursive indentation, so a query four levels deep may still want a manual pass. Within those two limits the transformation is safe and reversible: because strings and comments are preserved exactly and only whitespace and keyword case change, the formatted query executes identically to the one you pasted, and every byte is processed in your browser with nothing uploaded.