SQL Formatter

Twelve options: standard sql, postgresql, mysql, mariadb, sqlite, transactsql, bigquery, redshift, spark, n1ql, db2, and plsql. Picking the right one matters because each grammar treats quoting and identifiers differently, and the sql formatter online parses your statement fully before reformatting it.

Because parsing is dialect-aware. Square-bracket identifiers only make sense to transactsql, backticks belong to mysql and its relatives, and a PostgreSQL double-colon cast confuses everything else. When you see a Could not format error, the first fix to try is selecting the dialect the query was written for.

No. The tool moves whitespace and line breaks; it doesn't reorder joins, rewrite predicates, or touch literals. The formatted statement is equivalent to the original once whitespace is normalized, so it's safe to use on production SQL.

Here, yes, because nothing is uploaded. The parsing and formatting run entirely in your browser, so when you format sql query online on this page, schema names, table names, and literals stay on your machine. Still, strip real customer values out of literals before sharing the query anywhere.

No, your casing is preserved. If you wrote select in lowercase, it stays lowercase; the sql beautifier only repositions tokens onto indented lines. Teams that want uppercase keywords should settle that convention in review rather than expecting the tool to enforce it.

Two spaces per level. Clauses like SELECT, FROM, WHERE, and GROUP BY start their own lines, and the expressions under them indent one step. It's compact enough for long queries to stay on screen and consistent enough to diff.

Each clause on its own line means a reviewer can comment on a single join or condition instead of the whole statement. Long boolean chains become scannable, and a stray cartesian join is much harder to miss when every JOIN sits at the same indent level.