SQL Formatter

How to use this SQL formatter

SQL Formatter features

When SQL formatting helps

Consistent SQL formatting makes joins, filters, grouping, subqueries, and long select lists easier to review. It is useful before code review, documentation, debugging, sharing a query in an issue, or turning a quick database console query into something maintainable.

How the formatter works

This SQL formatter runs in the browser. The selected dialect controls parsing rules and keywords; the formatting options control casing, indentation, and blank lines. The tool formats SQL text but does not execute, optimize, or validate query results.

SQL formatter FAQ

Format SQL without changing what it means

Formatting makes a query easier to inspect, but it does not prove that the query is correct. Read the formatted output before running it. Pay particular attention to join conditions, Boolean precedence, subqueries, window clauses, and statements that modify data. Whitespace and keyword case are usually cosmetic, yet a formatter can misunderstand vendor-specific syntax or an incomplete statement.

Choose the dialect that matches the database executing the query. PostgreSQL, MySQL, SQL Server, SQLite, BigQuery, Snowflake, and other systems share a large vocabulary but differ in quoting, functions, data types, operators, and procedural extensions. A query can format cleanly under the wrong dialect and still fail or behave differently. When the dialect is uncertain, preserve the original and test in a disposable environment.

For example, the official PostgreSQL SQL syntax documentation defines that database's lexical and expression rules. Use the corresponding official manual for the selected engine and version instead of assuming another dialect's formatter options are compatible.

Use formatting as part of review, not as a substitute for parsing or execution planning. A database parser can identify syntax errors that a text formatter does not. An execution plan can reveal a missing index, unintended full scan, or large intermediate result. Run potentially expensive reads with an appropriate limit during exploration, and use a transaction or staging database for changes.

Comments deserve a manual check. A formatter may move line breaks around a comment, and comment syntax can vary by database or client. Confirm that hints, migration directives, template placeholders, and copied console prompts remain attached to the intended statement. Do not paste secrets, production credentials, customer data, or complete database dumps into any tool when a small representative query will do.

For a useful before-and-after review, keep the original query beside the output and compare tokens rather than visual shape alone. Check string literals, quoted identifiers, numeric values, parameters, operators, and statement order. A version-control diff is helpful for a long migration, but a noisy whitespace diff can hide a meaningful edit. Format first, then make logic changes in a separate commit or review step.

A good style is consistent enough that a teammate can scan it quickly. Break major clauses onto separate lines, indent nested expressions, and use aliases that explain the role of each table. Avoid aligning columns with long runs of spaces because small edits create large diffs. Follow the project's existing convention for keyword case and commas instead of treating one style as universally correct.

Before executing a formatted write statement, answer three questions: which rows can it touch, how can the change be checked, and how can it be reversed? Preview an UPDATE or DELETE predicate with a matching SELECT. Confirm row counts inside a transaction when the database supports it. Backups and rollback plans belong outside this formatter, but they are part of safely using its output.

The query is formatted in the browser for this page's workflow; the tool does not connect to your database or validate its schema. That protects against accidental execution, but it also means table names, columns, permissions, constraints, and current data are unknown. Treat the result as edited text. The database and its official documentation remain the authority on syntax and behavior.

Parameter placeholders are another dialect boundary. A driver may use question marks, numbered parameters, named parameters, or a framework-specific template. Keep placeholders intact and bind values through the database driver rather than joining user input into SQL. Formatting cannot turn string interpolation into a safe parameterized query, and it cannot tell whether a dynamic identifier has been allow-listed.

For shared queries, add a short note that identifies the database version and expected inputs. Include a representative result shape or test fixture when the query supports business logic. This makes review about behavior rather than indentation. It also helps future maintainers detect when a schema migration has made a previously valid query ambiguous or slow.

• For a read, verify filters, joins, grouping, ordering, limits, and how null values are handled.
• For a write, verify the transaction boundary, affected-row expectation, constraints, triggers, and rollback path.
• For generated SQL, capture the bound values separately and reproduce the issue in a safe database rather than pasting production data.

Final review checklist