SQL formatter — pretty print queries offline

A SQL query is a description of your database. Table names, column names, join structure, business rules encoded as WHERE clauses — a single query can reveal more about how a company works than a page of documentation, and production queries frequently carry literal customer identifiers and email addresses in their predicates.

Formatting here runs with the open-source sql-formatter library in your browser, live as you type. Nothing is transmitted; the site has no backend, and a Content-Security-Policy blocks third-party requests. Load the page, disconnect, and it still formats.

Pick the dialect that matches your database — standard SQL, plus PostgreSQL, MySQL, SQLite, and BigQuery. It matters more than it sounds: dialects differ in quoting rules, in how they treat certain operators, and in which words are reserved, so formatting with the wrong one can produce output that reads oddly or breaks an identifier.

Keyword casing is a separate choice. UPPERCASE keywords against lowercase identifiers is the long-standing convention, and it earns its keep on long queries by making the structure scannable — you can find every JOIN and WHERE at a glance. Lowercase is increasingly common in modern codebases. Either way, identifiers are left exactly as you wrote them, since in case-sensitive databases changing them would change their meaning.

A formatter changes whitespace, line breaks and keyword casing. It does not check your query against a database, so it cannot tell you a table or column doesn't exist, and it won't catch a misspelled keyword — SELEC a FORM t passes through untouched, because to the formatter those are just identifiers. Run the query against your database (or its EXPLAIN) to find out whether it is valid.

What it does catch is SQL it can't parse at all — an unclosed bracket or an unterminated string literal. You get an error with the line and column instead of output. If a query you know is fine fails to parse, the dialect is usually the cause: backtick-quoted identifiers only parse as MySQL, and $1-style placeholders only as PostgreSQL.

Comments are kept. Both -- line and /* block */ comments stay where they were, so annotated queries survive the round trip. Several statements separated by semicolons are formatted one after another, with a blank line between them.

Unformatted SQL arrives constantly — dumped from an ORM's debug log, extracted from an application trace, or pasted from a colleague as one enormous line. Reading a 400-character single-line query is genuinely difficult, and subtle mistakes hide in it: a join condition that silently became a cross join, a misplaced OR that widens a WHERE clause far beyond what was intended, a subquery correlated by accident.

Formatting is also what makes queries comparable. Two versions of the same query formatted consistently can be dropped into the diff checker, where the real change stands out instead of being buried in whitespace differences. Related and equally local: code formatter for HTML, CSS and JavaScript, and JSON formatter for query results.