How to Format SQL Online Without Uploading Your Query

What the formatter actually changes

It re-indents the statement and sets the case of keywords, and it does not rewrite what you wrote. Identifiers, string contents and numbers come out as they went in. Keyword casing is a display choice with a visible trade-off: UPPER CASE makes a long query easier to scan, while lower case keeps a diff small when the original was lower case, which matters more than it sounds if the file is under version control and someone else reviews it.

The default dialect is PostgreSQL and there are 21 to choose from: BigQuery, ClickHouse, Db2, Db2i, DuckDB, Hive, MariaDB, MySQL, N1QL, Oracle PL/SQL, PostgreSQL, Redshift, Spark, SQLite, standard SQL, TiDB, Trino, Transact-SQL, T-SQL, SingleStoreDB and Snowflake. The dialect decides the small things that differ between engines: how a backslash behaves inside a string, and whether a dollar-quoted body is a string or a language block. Pick the one you actually run it on, or the output can differ from what your database would accept.

1. Paste the statement

The box starts empty; use Load sample if you want something to look at first. Nothing is pre-filled, so what you see is only ever your own query.

The input limit is 100,000 characters. Past that the query is refused with its real size rather than truncated, because half a statement formats into SQL that still parses and is now wrong, and nothing in the output tells you that happened.

2. Choose a dialect and an indent

Set Language to your database, then pick an indent of 2 or 4 spaces or a real tab. The tab option inserts a tab character rather than a backslash followed by a t, which is the small thing that makes copied SQL from this page behave in an editor that shows whitespace.

3. Read the result

The output updates as you type, and the panel tells you how many characters came out of how many in. Copy takes the formatted statement to the clipboard; download writes a .sql file.

If the panel reports that the SQL could not be formatted, the output area stays empty and Copy stays disabled. There is no partial result to copy by accident, which is the point: an error message pasted into a terminal is worse than an empty box.

The three things it refuses, and why

An unterminated block comment is the important one. If you paste a query with a missing */ , a naive formatter reads the rest of the comment as arithmetic and hands back SQL whose tokens are not the ones you sent. That is the failure this page is built to prevent, so the comment state is tracked before any formatting and the query is refused instead.

A nested block comment is refused in dialects that do not support nesting, because the inner */ would close the outer comment early and change the statement. PostgreSQL, DuckDB, Db2i and SQL Server do support nesting, and those queries are formatted normally. And unbalanced parentheses are counted and reported rather than passed on, because a parser given 507 characters of broken input can return an error message over 16 million characters long — which is why the message here is capped at 240 characters and never rendered into the output box.

Caps, privacy, and what it is not

Four limits are checked before formatting starts: 100,000 characters of input, 200 levels of parenthesis nesting, 64 levels of nested comment, and the 240-character error message. Each is refused with its real number.

Formatting happens in this tab. No request is made with your query, which is the part that matters when the query is a WHERE clause full of values you are not supposed to be pasting anywhere. What this page does not do is tell you whether your query is correct, whether it uses a column that exists, or whether it would return what you meant. It reads the shape of the statement and lays it out; a query that formats perfectly can still be the wrong query.