SQL formatter and beautifier
Format, beautify and indent SQL queries across major dialects. Runs entirely in your browser.
Runs 100% in your browserHow to format SQL
- Paste your SQL. Paste a single query or a whole script — often pulled one-line from a log or an ORM.
- Pick the dialect and casing. Choose the database that matches your query and how keywords should be cased.
- Copy the formatted query. Copy the indented, one-clause-per-line result back into your editor or migration.
What gets changed — and what never does
A query copied out of an application log, an ORM's debug output or a one-line script arrives as a dense
wall of text. Formatting fixes exactly three things: it puts each major clause
(SELECT, FROM, WHERE, JOIN, GROUP BY)
on its own line, indents nested expressions and parenthesised lists so structure is visible, and applies
consistent keyword casing. Everything that affects meaning is left alone — your identifiers, string
literals, comments and the order of operations are untouched. The formatted query is exactly equivalent to
the one you pasted; only its readability changes.
Why the dialect picker is there
"SQL" is really a family of dialects that disagree on keywords, quoting and operators. To lay a query out
correctly the formatter has to recognise those tokens, so it asks which database you're targeting.
PostgreSQL uses :: for casts and dollar-quoted strings; MySQL and MariaDB quote identifiers
with backticks; Transact-SQL (SQL Server) uses [square brackets]; BigQuery and Snowflake add
their own functions. Pick the matching dialect and those stay intact instead of being misread as
something else.
A consistent style pays off in review
Running every query through the same formatter before it lands in a migration or a pull request means diffs show real logic changes, not whitespace noise — two formatted versions line up cleanly in the diff checker. It's the same habit that keeps JSON and other structured text reviewable: format on the way in, and the next person to read it (often you) starts from something legible.
Frequently asked questions
- It rewrites only the whitespace and keyword casing: each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY) starts on its own line, nested expressions and parenthesised lists are indented, and keywords are cased consistently. The result is the same query, laid out so you can actually read and review it.
- Each database has its own keywords and operators, and the formatter needs to recognise them to lay the query out correctly. PostgreSQL's
::casts, MySQL's backtick-quoted identifiers, T-SQL's[bracketed]names and BigQuery's functions all differ — choosing the matching dialect (PostgreSQL, MySQL, MariaDB, SQLite, BigQuery, Snowflake, Transact-SQL and more) keeps those intact instead of mangling them. - No. The changes are purely cosmetic — line breaks, indentation and keyword casing. Your table and column names, string literals, comments and the logic itself are untouched, so the formatted query is exactly equivalent to the original.
- Yes. Named (
:id), numbered ($1) and positional (?) placeholders are preserved as-is, so a query copied out of application code or an ORM log formats without breaking its bind parameters. - Yes — paste multiple statements separated by semicolons and each is formatted in turn. It is just as happy with one long SELECT as with a migration file of several statements.
- No. Formatting runs entirely in your browser; a query containing real table names or embedded values never leaves your device.