SQL Formatter & Beautifier

What it does & when you need it

You've inherited a query that arrives as one long line — a SELECT with three joins, a tangle of conditions, and no line breaks in sight — and you need to actually read it before you dare touch it. This tool pretty-prints SQL: it inserts consistent indentation and line breaks so clauses, joins, and predicates stack up where your eye expects them. Paste a query pulled from an ORM log, a stored procedure, or a copy-pasted one-liner from a coworker, pick the dialect it was written for, and get back something you can review, diff, or paste into a migration. Everything runs in your browser, so a query that embeds table names, schema details, or literal values from production never leaves your machine.

How to use

Paste your statement into the input.sql buffer, press Sample to load an example multi-join SELECT, or Upload a .sql file.
Choose the Dialect that matches where the query runs — Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, BigQuery, or SQL Server (T-SQL). Toggle Uppercase keywords on or off to match your team's house style.
The formatted output updates as you type. Press Format or Ctrl/Cmd + Enter to copy the result, or use the Copy button on the output buffer.

Things worth knowing

Formatting is purely cosmetic. Reformatting only rearranges whitespace and line breaks — it never rewrites your logic, reorders clauses, or changes which rows come back. A minified one-liner and its pretty-printed version are the same statement to the database engine; the only audience for the extra spacing is the humans reading the code. That also means it's safe to run on a query you don't fully understand yet: you get readability without altering behavior.

The dialect you pick genuinely matters. SQL is a family of dialects, not one language, and they disagree on syntax the formatter has to respect. Identifier quoting is the classic trap: MySQL and MariaDB wrap identifiers in backticks (`user`), while PostgreSQL, SQLite, and the ANSI standard use double quotes ("user"), and SQL Server uses square brackets. Row-limiting differs too — Postgres and MySQL use LIMIT, whereas SQL Server historically reaches for TOP. Choosing the wrong dialect can make the formatter mishandle a quoted name or a dialect-specific keyword, so match it to your actual database.

Uppercasing keywords is a widely followed convention. Rendering reserved words like SELECT, FROM, WHERE, and JOIN in uppercase while leaving your table and column names in their original case makes the skeleton of a query pop out at a glance — you can trace the clause structure without reading every token. It carries no meaning to the engine (SQL keywords are case-insensitive), but as a readability habit it's close to universal in style guides, which is why the toggle defaults to on.

Formatting is not sanitizing. Making a query readable does nothing to make it safe. Never assemble SQL by concatenating user input into a string — that's exactly how SQL injection happens. Use parameterized queries or prepared statements and let the driver bind values separately from the statement text. Treat this tool as a formatter for queries you already trust, not a cleaning step for untrusted input.

Once your SQL reads cleanly, you might format a JSON payload returned by the same service, tidy the JavaScript that builds the query, or turn a CSV export into JSON for a seed script.

Examples

Multi-join SELECT one-liner

select u.id, u.name, o.total from users u join orders o on o.user_id = u.id where o.total > 100 order by o.total desc limit 20;

Stacks each clause and join onto its own line for review.

PostgreSQL upsert

insert into events(id,type,payload) values(1,'click','{}') on conflict (id) do update set type = excluded.type;

Pick the PostgreSQL dialect so ON CONFLICT and double-quoted identifiers format correctly.

Frequently asked questions

Does formatting change what my query returns?

No. Formatting only adjusts whitespace, line breaks, and keyword case. The parsed statement is identical to the database engine, so the same rows come back before and after.

Why do I need to pick a SQL dialect?

Dialects differ on syntax the formatter must respect — MySQL quotes identifiers with backticks while PostgreSQL uses double quotes, and row limits use LIMIT versus SQL Server's TOP. Matching the dialect avoids mangling dialect-specific tokens.

Should SQL keywords be uppercase?

Keywords are case-insensitive to the engine, but uppercasing SELECT, FROM, and WHERE while leaving identifiers alone makes a query's structure scannable. It's a near-universal style convention, so the toggle defaults to on.

Is my query sent to a server?

No. Formatting runs entirely in your browser, so queries containing schema names or literal production values never leave your machine — nothing is uploaded or logged.

Does formatting protect against SQL injection?

No. Formatting is cosmetic, not sanitizing. Never build SQL by concatenating user input; use parameterized queries or prepared statements so the driver binds values separately from the statement text.

How to use SQL Formatter