SQL Formatter: Beautify SQL Queries Online

Why format SQL at all

SQL is whitespace-insensitive, so the database does not care if your query is one 900-character line. Humans do. A formatted query puts each clause (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) at the left edge and indents what belongs to it. You can see the shape of the query before you read a single column name.

That shape is where bugs hide. A join condition that drifted into the WHERE clause, an OR that is missing parentheses, a subquery that returns more rows than you think. On one line these are invisible. Formatted, they jump out.

How this formatter works

It runs the open-source sql-formatter library directly in your browser. The library tokenizes your query with the grammar of the dialect you pick, then rebuilds it with consistent line breaks and indentation. It does not execute anything and it does not connect to a database. The library only downloads when you open this page, and your query never leaves the tab.

That matters more than it sounds. Production queries contain table names, customer IDs, email addresses, and sometimes credentials in connection strings. Several popular online formatters send your SQL to a server to format it. This one cannot, because there is no server step.

Pick the right dialect

Dialects disagree on the details. MySQL quotes identifiers with backticks; PostgreSQL and standard SQL use double quotes; SQL Server uses square brackets. PostgreSQL has the :: cast operator and dollar-quoted strings. BigQuery allows dashes in project names. T-SQL has TOP instead of LIMIT. If you format with the wrong dialect, the tokenizer can misread these and either error or split something it should not.

Rule of thumb: pick the database the query will run on. If you are not sure, Standard SQL handles most plain SELECT, INSERT, UPDATE, and DELETE statements. Your choice is remembered in this browser for next time.

Worked example

Input: select u.id, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.country in ('US','CA') group by u.id having count(o.id) > 2 order by orders desc limit 25;

Output with uppercase keywords and 2-space indent puts SELECT on its own line with u.id and COUNT(o.id) AS orders indented under it, then FROM users u, then LEFT JOIN orders o ON o.user_id = u.id, then WHERE, GROUP BY, HAVING, ORDER BY, and LIMIT each starting a new line. Now it is obvious that the HAVING filters on the aggregate and the WHERE filters on the raw rows, which is exactly the distinction people get wrong.

Uppercase keywords: convention, not rule

Uppercase keywords (SELECT, FROM, WHERE) are the most common style because they separate the language from your identifiers at a glance. Many modern teams prefer lowercase for less shouting. Neither affects execution. Choose one and keep it consistent across a codebase; mixed case in the same file is the only wrong answer. Preserve leaves your casing exactly as typed.

Pitfalls to watch for

Template placeholders. Queries with ORM or driver placeholders such as ?, $1, :name, or @param usually format fine. Templating syntax like {{ table }} from dbt or Jinja may not, because it is not SQL. Format the rendered query, or temporarily replace the template tags.

Parse errors are real signals. If the formatter says it cannot parse at a certain line and column, look there first. The usual causes are an unclosed parenthesis, a missing comma between columns, or a quote that was never closed. Fix it here and you catch it before the database does.

Minify strips comments. The minify button removes -- and /* */ comments and collapses whitespace so a query fits on one line for logs or config files. Quoted strings are left untouched. If a comment carries meaning, such as an optimizer hint in MySQL written as /*+ ... */, keep the formatted version instead.

Stored procedures and very long scripts. Procedural blocks (PL/pgSQL, T-SQL BEGIN ... END) are supported to a degree, but deeply procedural code may format less neatly than plain queries. The formatter never changes what the code does; worst case, it leaves a section less tidy than you would like.