SQL formatter

Pretty-print SQL by dialect.

Dialect

A query comes out of an ORM log or a bug report as one unbroken 400-character line, and reading it means counting parentheses by eye. Formatting it first is usually faster than trying to debug it as-is.

Paste the query, pick the dialect it was written for, and press Format. The indented version appears below with a Copy button.

How it works

Choosing a dialect

The Dialect dropdown tells the formatter which grammar to expect. It matters because each database adds keywords and syntax the others don't have:

Dialect	Why you'd pick it
Standard SQL	Portable queries, or when you're unsure
MySQL	Backtick-quoted identifiers, `LIMIT n, m`
PostgreSQL	`::` casts, `RETURNING`, dollar-quoted strings
MariaDB	MySQL-compatible syntax
SQLite	Lightweight subset, `AUTOINCREMENT`

Picking the wrong one usually still works, but dialect-specific tokens may be indented as if they were plain identifiers.

What formatting does

The formatter re-indents the query at two spaces per level and uppercases keywords — select becomes SELECT, left join becomes LEFT JOIN. Clauses go on their own lines, and nested subqueries and parenthesised conditions are indented to show how deeply they sit. Your identifiers, string literals, and comments are left exactly as written; only whitespace and keyword casing change.

That last point is worth stressing: this is a formatter, not a linter or an optimiser. It will happily format a query that has a syntax error or that would scan your whole table. If the input is badly malformed, an error message appears instead of output.

Placeholders and parameters

Queries pulled from application logs often still contain ?, :name, or $1 placeholders. Those pass through untouched, so you can format a prepared statement without substituting values first — handy when the values are the sensitive part.

Everything runs in your browser, so nothing is uploaded. Even so, treat query text pulled from production as sensitive and strip real customer data before pasting it anywhere.

Terms explained

Dialect: The specific SQL variant a database understands. Databases share a common core but differ in quoting, functions, and extensions.
Keyword case: Whether reserved words like SELECT and JOIN are upper or lower case. This tool uppercases them; it's a readability convention, not a requirement.
Indent width: How many spaces each nesting level adds. Fixed at two here, which keeps deeply nested subqueries from running off the right edge.
Placeholder: A stand-in for a value in a prepared statement — `?`, `:name`, or `$1` depending on the driver. Passed through unchanged.
CTE: A Common Table Expression, the `WITH name AS (...)` form. Formatting these is where the indentation helps most, since each CTE gets its own block.

Frequently asked questions

Does formatting change what my query does?

No. Only whitespace and keyword capitalization change. Table names, column names, string literals, and comments are preserved exactly, so the formatted query is equivalent to the original.

What happens if I pick the wrong dialect?

In most cases it still formats fine, because the dialects share a large common core. You'll notice the difference on syntax unique to one database — Postgres `::` casts or MySQL backticks — which may be laid out less cleanly.

Will it tell me if my SQL is wrong?

Not reliably. It's a formatter, not a validator. Severely broken input produces an error message, but a query that parses yet references a missing column will format without complaint. Run it against your database to check correctness.

Can I format a query that still has ? or :name placeholders?

Yes. Placeholders are treated as ordinary tokens and passed through unchanged, so you can format a prepared statement straight from a log without filling in values.

Is my query sent anywhere?

No. Formatting happens in your browser. That said, production queries often embed real data — strip anything identifying before pasting it into any tool.