SQL Formatter

About SQL Formatter

A SQL formatter takes a cramped, one-line query and lays it out with proper indentation, keyword casing, and line breaks so it's easy to read and review. Paste your SQL, pick your dialect — standard SQL, PostgreSQL, MySQL, SQLite, SQL Server, or BigQuery — and it beautifies the query instantly. It runs in your browser, so your queries stay private.

Why formatting changes what you notice

A long query written on one line hides its own structure. Put each clause on its own line and each join on a new line with its condition indented beneath, and the shape of the query becomes visible: how many tables are involved, which joins have conditions and which do not, where the filtering happens. Missing join conditions — the classic cause of an accidental cross join returning millions of rows — are almost invisible inline and obvious once formatted.

This is why formatting is a review tool rather than a cosmetic one. The same query, reformatted, frequently reveals a duplicated condition, a filter applied in the wrong clause, or a join that was meant to be a left join and is not.

Dialects are genuinely different languages

SQL is standardised in theory and divergent in practice. Identifier quoting alone differs: PostgreSQL and standard SQL use double quotes, MySQL traditionally uses backticks, SQL Server uses square brackets. String concatenation, the syntax for limiting rows, date functions, and upsert behaviour all vary. A formatter has to know the dialect to parse the query correctly rather than choking on a construct it does not recognise.

This also matters when moving a query between systems. A query that formats cleanly under one dialect and fails under another is telling you something useful about portability before you try to run it.

Formatting conventions worth adopting

Uppercase keywords and lowercase identifiers is the most common convention, because it makes the language and your schema visually distinct at a glance. Leading commas — placing the comma at the start of each line in a select list — look odd at first but make it much easier to comment out or reorder a column without creating a syntax error.

Consistent indentation for subqueries and CTEs matters most in long queries. A common table expression laid out with its own indented block reads like a named step; the same logic buried as a nested subquery in a where clause reads like nothing at all. Where a query is complex enough to need explaining, restructuring it into CTEs is usually better than commenting it.

Formatting is not optimising

Whitespace and casing have no effect on how a query runs. The planner parses the text into a tree and optimises from there, so a beautifully formatted query and a one-line version execute identically. If a query is slow, the answer is in the execution plan, the indexes, and the volume of rows touched — not the layout.

One caveat where formatting has a real cost: some databases cache plans keyed on the exact query text, so reformatting a query can look like a new statement and miss a cached plan on its first run. That is a one-off cost and not a reason to keep queries unreadable, but it explains an occasional slow first execution after a tidy-up.

Frequently asked questions

Which SQL dialects are supported?

Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server (T-SQL), and BigQuery. Picking the right dialect makes the formatter handle that database's specific keywords and syntax correctly.

Does formatting change what my query does?

No. It only adds whitespace, line breaks, and consistent keyword casing — the query runs exactly the same, it's just easier to read.

Is my SQL sent to a server?

No. Formatting runs entirely in your browser, so your queries — including any table or column names — never leave your device.