Does formatting change what the query does?

No. Only whitespace, line breaks and keyword casing change; the statement is semantically identical.

Which dialect should I choose?

The one your database actually speaks. Dialects differ in reserved words and syntax, and the wrong choice can produce odd indentation around constructs the formatter does not recognise.

Can it format a query with parameter placeholders?

Yes — the common placeholder styles ($1, ?, :name) are preserved.

Are my queries sent to a server?

No. Everything happens in your browser — nothing you enter is uploaded, and the tool keeps working with no network connection.

SQL Formatter · OneUtil

Formatting live as you type. A half-finished statement keeps the last good output on screen.

Samples

Statements1Input431 charsOutput—Looks likePostgreSQL`::` cast

SQL in

Formatted

Nothing to show yet

The query could not be parsed and there is no earlier result to fall back on.

What this does — and what it doesn't

Formatting rewrites whitespace and letter case only. Your query’s logic, identifiers and literals are never altered.
Every option above is one sql-formatter actually implements. It has no comma-position setting — where a line breaks is decided by Expression width.
Minify is ours, not the library’s: it tokenises first, so two spaces inside a string literal and a -- inside quotes survive untouched.
Dialect detection is a heuristic over recognisable syntax, not a parser. It only speaks up when the evidence is strong, and it always shows what it saw.
Nothing leaves your browser — the formatter and the tokeniser both run in this tab.

About SQL Formatter

Pretty-print or minify SQL across 20 dialects, formatted live as you type, with your queries never leaving the browser.

What it does

Paste a query — including the single-line monster your ORM logged — and get readable, consistently indented SQL. Formatting updates as you type, and minification goes the other way when you need a query on one line for a config file.

Twenty dialects

PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), SQLite, Oracle PL/SQL, BigQuery, Snowflake, Redshift, Db2, Hive, Spark and others. Dialect choice matters because each has its own reserved words and syntax quirks — picking the right one keeps identifiers and functions from being mangled by a formatter that does not recognise them.

Safe for production queries

Queries routinely contain table names, column names and literal values that reveal how a system is built. Nothing here is uploaded, so pasting a real production query costs you nothing.

Common questions

Does formatting change what the query does?: No. Only whitespace, line breaks and keyword casing change; the statement is semantically identical.
Which dialect should I choose?: The one your database actually speaks. Dialects differ in reserved words and syntax, and the wrong choice can produce odd indentation around constructs the formatter does not recognise.
Can it format a query with parameter placeholders?: Yes — the common placeholder styles ($1, ?, :name) are preserved.
Are my queries sent to a server?: No. Everything happens in your browser — nothing you enter is uploaded, and the tool keeps working with no network connection.

Related tools

Regex Tester — Live matches, a token-by-token explanation, and portability notes.
Cron Parser — Build schedules visually, explain them, preview next runs.
Color Converter — Named colours, harmonies, contrast, and vision simulation.
Password Generator — Strong passwords and passphrases, with an honest strength estimate.