Turn unreadable one-line SQL into cleanly indented, consistently cased queries. Supports MySQL, PostgreSQL, SQLite, SQL Server, MariaDB, and BigQuery dialects — formatted entirely in your browser.
SQL is one of the few languages where a 400-character statement routinely arrives as a single line — copied out of application logs, an ORM's debug output, a BI tool, or a colleague's Slack message. Unformatted SQL isn't just ugly; it actively hides bugs. A misplaced AND/OR precedence problem, a join condition accidentally placed in the WHERE clause, a subquery filtering on the wrong alias — all of these are nearly invisible on one line and jump out immediately once each clause sits on its own indented line. Formatting is the first step of debugging someone else's query, and the last step before committing your own.
Consistent style also compounds across a team: when every query in the codebase puts keywords in the same case and clauses at the same indent, code review diffs shrink to the lines that actually changed. The conventions this tool applies — keywords uppercased, one clause per line, indented select lists and join conditions — mirror the style guides used by most data teams.
SQL dialects disagree about surprisingly fundamental syntax: MySQL quotes identifiers with backticks (`order`), SQL Server with brackets ([order]), PostgreSQL with double quotes; T-SQL has TOP, the others LIMIT; BigQuery allows EXCEPT(col) in a select list; PostgreSQL's cast operator :: appears nowhere else. A formatter that parses your query with the wrong grammar can mangle these constructs, so choose the dialect you're actually writing — the formatting engine (the same open-source library behind many IDE plugins) then knows every keyword and operator your database accepts.
The Minify button does the reverse job: collapsing a formatted query back to a compact single line, string literals preserved intact — handy when embedding SQL in JSON configs, environment variables, or log-friendly one-liners. If you're comparing two versions of a query, format both and diff them with our Text Diff tool; the clause-per-line layout makes the comparison meaningful.
No — formatting runs entirely in your browser. Queries revealing your schema, table names, and business logic never leave your machine.
No — only whitespace and keyword casing change. Identifiers, literals, and structure are untouched, so the formatted query executes identically. (Identifier case is also preserved, since some databases treat quoted identifiers as case-sensitive.)
Usually a dialect mismatch — T-SQL brackets or PostgreSQL casts confuse the standard-SQL grammar. Switch the dialect and retry. Genuinely malformed SQL (unbalanced parentheses, an unclosed string) also fails, which makes the formatter a handy first-pass syntax check.
Yes — paste a whole script with semicolon-separated statements and each is formatted in sequence, blank-line separated in the output.
Databases don't care; humans do. Uppercase keywords are the long-standing convention because they visually separate structure from your identifiers — but modern teams with good syntax highlighting increasingly go lowercase. Match whatever your existing codebase does.
No — formatting is purely cosmetic. For performance work, run EXPLAIN in your database; a formatted query just makes the plan discussion easier to have.
Yes — placeholders (?, $1, :name, @param) pass through untouched, so queries copied from ORMs and drivers format cleanly. DDL (CREATE TABLE, ALTER), DML, CTEs (WITH), and window functions are all understood by the grammar.
Yes — both -- line and /* block */ comments are preserved and re-indented alongside the code they annotate. That makes the formatter safe for annotated queries kept in version control, where losing comments would be unacceptable.