SQL Formatter

Beautify SQL queries with dialect-aware keyword casing and indentation.

SQL

Dialect

Input0 chars

Formatted

Private by design. Everything runs locally in your browser. Your input is never uploaded, logged or stored on a server.

How to use the SQL Formatter

Paste the query — one statement or a whole script.
Pick the dialect so that dialect-specific keywords are recognised.
Choose whether keywords come out upper case, lower case or as written.
Copy the formatted query.

A worked example

Input

select id,name from users where active=1 order by name

Output

SELECT
  id,
  name
FROM
  users
WHERE
  active = 1
ORDER BY
  name

Formatting is what makes a long WHERE clause reviewable in a pull request. The query itself is unchanged, character for character, once whitespace is normalised.

Frequently asked questions

Which SQL dialects are supported?

Standard SQL plus PostgreSQL, MySQL, MariaDB, SQLite, BigQuery, Snowflake, Redshift, Transact-SQL, PL/SQL and Db2.

Does formatting change what my query does?

No. Only whitespace and keyword casing change. The parsed statement is identical.

Is my query sent anywhere?

No. The formatter runs as JavaScript in your browser. No database connection is opened and no query is transmitted.

Can it format multiple statements at once?

Yes. Statements separated by semicolons are each formatted and kept in order, with a blank line between them.

What happens if I pick the wrong dialect?

You get a parse error naming the line and column of the first token that dialect does not recognise — a PostgreSQL :: cast formatted as MySQL, for example. It never silently returns a different query.

Are comments and parameter placeholders preserved?

Yes. Line comments stay on the line they annotated, block comments keep their position, and positional ? and named :id placeholders are passed through unchanged.

About the SQL Formatter

Generated SQL — from an ORM, a log line or a BI tool — usually arrives as one long line. This formatter breaks it into clauses, indents subqueries and joins, and normalises keyword casing so the shape of the query becomes visible before you try to read it.

Pick the dialect that matches your database. Dialect-specific syntax such as PostgreSQL :: casts, MySQL backtick quoting and BigQuery backtick-qualified table names are only parsed correctly when the right dialect is selected.

Picking the wrong dialect is not silently destructive. Syntax the selected dialect does not recognise stops with a parse error naming the line and column, rather than producing a reformatted query that means something else. A PostgreSQL :: cast formatted as MySQL halts at the cast, which is usually the fastest way to find out that a query came from a different database than you assumed.

Comments and placeholders survive. A trailing -- note stays attached to the line it annotated, a leading /* block */ keeps its position, and both positional ? and named :id parameters pass through untouched — so a statement copied out of a prepared-statement log can be read here and put back without editing. Indentation is two spaces, and statements separated by semicolons keep their order with a blank line between them.

The reason to format before committing is the diff. Generated SQL on one line produces a diff where every edit looks like the whole query changed; the same query broken onto clause lines produces a diff that points at the clause someone actually edited. That is also why keyword casing is a setting rather than a fixed choice: matching what the surrounding code already does keeps the diff down to the lines that changed.

Formatting is purely cosmetic. Nothing is executed, no connection is made, and the semantics of your query are unchanged.

Maintained by Ikonode. Last checked against the code on 11 September 2026.

What it does not do

Cosmetic only. No connection is opened and no query is executed.
It does not validate your SQL — a query with a typo in a column name formats perfectly.
Dialect affects how keywords are recognised, not whether the statement would run.