SQL formatter

Paste a SQL query and get it back indented and broken across lines, with keywords like SELECT, FROM, and WHERE on their own lines and consistent capitalization. Pick a dialect so dialect-specific syntax formats correctly, and choose keyword case and indent width to match your team’s style.

Which SQL dialects does it support?

You can format standard SQL, MySQL, PostgreSQL, SQLite, T-SQL (SQL Server), or BigQuery. Each dialect has its own quirks, such as backtick-quoted identifiers in MySQL or BigQuery’s array and struct syntax, and picking the right one means the formatter parses those correctly instead of tripping over syntax standard SQL doesn’t have. If you’re not sure which dialect a query belongs to, standard SQL is a safe default for anything that doesn’t lean on vendor-specific features.

Besides the dialect, you can set keyword case to uppercase, lowercase, or left as you typed it, and set the indent to two spaces, four spaces, or a tab. Uppercase keywords with a query written in lowercase, for instance, and every SELECT, JOIN, and GROUP BY gets capitalized without touching column or table names.

Does the query ever leave my browser?

No. Formatting happens entirely client-side using the sql-formatter library, which runs in JavaScript and does not make network requests. Nothing you paste is sent to a server, logged, or stored, so it’s fine to format a query that has real table names, customer data, or embedded values you wouldn’t want to paste into a random web form.

What if the formatter can’t parse my query?

If the SQL doesn’t parse under the selected dialect, the tool shows an error instead of guessing at a partial result. This usually means the wrong dialect is selected, there’s a genuine syntax error, or the query uses a feature the parser doesn’t recognize (some database-specific extensions or unusual comment styles can trip it up). Switching dialects or checking for a stray comma or unclosed parenthesis around the reported spot is usually enough to fix it.

When is this useful?

Common uses: cleaning up a one-line query copied from an ORM’s debug log, standardizing formatting before a code review, or turning a minified migration script back into something readable. For style conventions beyond what formatting alone can fix, such as naming and comment conventions, see the SQL Style Guide.