SQL Formatter

Beautify, minify or format SQL queries for any major dialect

Dialect

Indent

Uppercase keywords

How it works

SQL Formatter — Beautify, minify or format SQL queries for any major dialect. All processing happens in your browser — no upload, no signup, no email required. Free forever.

Last updated: 2026-05-06

Editor's note

We use this on production logs where someone embedded a 400-character query in a string field and we have to read it before the incident bridge fills up. The dialect dropdown is not a polish detail — it is the entire point. PostgreSQL's `RETURNING`, MySQL's backtick identifiers, T-SQL's bracket quoting, and BigQuery's `QUALIFY` each have their own keyword set, and picking the wrong dialect produces output that looks fine, compiles in your head, and then fails the moment you paste it into psql. We obsess about defaulting to the right dialect because "looks formatted" and "is formatted correctly" are not the same thing.

We refuse to upload your query, even though it would be marginally easier to run the formatter server-side. Production SQL is the most schema-revealing string in your codebase — table names, column names, business logic, and sometimes the literal customer IDs you were debugging. There is no version of "we promise we will not log it" that we trust, so we run sql-formatter in the browser and that is the end of the conversation. If the trade-off was clearer formatting in exchange for your schema in someone else's pipeline, we would still pick the browser every time.

About SQL Formatter

Pasting a 500-line SQL query that arrived as one continuous string is no way to debug a slow report. This SQL formatter pretty-prints any query with consistent indentation, uppercased keywords, and aligned clauses so JOIN, WHERE, GROUP BY and CASE expressions become instantly scannable. It is the same library (sql-formatter) that backs popular IDE plugins, exposed as a tool you can hit without installing anything.

Pick the dialect that matches your database to get the most accurate keyword recognition: Standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, T-SQL (SQL Server), BigQuery, Redshift, Snowflake and Trino are all supported. Dialect matters because each engine has reserved words, identifier quoting and built-in functions the others do not — formatting against the right dialect keeps your CTE names, JSON path expressions and dialect-specific keywords looking right.

Formatting only adjusts whitespace and case. Identifiers, literals, comments and the actual semantics of the query are preserved exactly — so the formatted output produces identical results to the original. And because everything runs locally in your browser, the query (which often contains real schema names, IDs, and business logic) never crosses the network.

How to use SQL Formatter

Paste your SQL query (single-line or multi-line) into the input box.
Choose the Dialect that matches your database for accurate keyword and identifier handling.
Set the Indent (2 or 4 spaces are typical) to match your team's style.
Toggle "Uppercase keywords" on if your style guide capitalises SELECT, FROM, JOIN.
Click Format for a readable layout, or Minify to collapse the query into one line for embedding in code.
Copy the result into your editor, migration script or pull request review.

Common use cases

Cleaning up a query that arrived as a single line in a log entry or a JSON API response.
Standardising SQL inside a code review so reviewers can spot the actual logic change, not formatting noise.
Reformatting auto-generated ORM SQL into something a human can debug for performance.
Minifying a query before embedding it as a string literal in application code, then formatting it back when debugging.
Producing readable EXPLAIN target queries for a runbook or incident postmortem.

Tips & common mistakes

If keywords like "QUALIFY" or "PIVOT" do not get capitalised, you probably picked the wrong dialect — they are recognised as keywords only in BigQuery / Snowflake / T-SQL respectively.
Trailing semicolons and comments are preserved. If your downstream tool rejects them, strip them after formatting.
Formatting cannot fix a syntax error. If a query refuses to format, run it through your DB's parser first to find the missing parenthesis or comma.
For very long queries, formatting is more useful when keywords stay aligned and you indent generously (4 spaces) — readability wins over compactness once a query no longer fits on one screen.

Frequently asked questions

Which SQL dialects are supported?

Standard SQL plus MySQL, PostgreSQL, SQLite, MariaDB, T-SQL (SQL Server), BigQuery, Redshift, Snowflake and Trino. Pick the dialect for the most accurate keyword and identifier handling.

Is my query sent to your server?

No. Formatting runs entirely in your browser using the sql-formatter library. The query never leaves your device.

Will it change the meaning of my query?

No — the formatter only adjusts whitespace and casing. The actual SQL semantics, identifiers and string literals are preserved exactly.

Can I format dialect-specific syntax like PostgreSQL JSON operators or BigQuery STRUCT literals?

Yes — pick the matching dialect and operators like ->>, #>>, [].* and STRUCT(...) keep their meaning. Formatting only re-aligns whitespace; it never rewrites operators or types.

Does the formatter validate that the SQL is correct?

Only loosely. It parses enough to know where clauses start and end, but it is not a full SQL parser — invalid queries can still come out "formatted". Use your database's EXPLAIN or dry-run for real validation.

Will Minify produce a shorter query than my hand-written one-liner?

Usually yes — it strips redundant whitespace, normalises commas and removes blank lines, but it preserves comments unless you delete them yourself. Useful when you need the query as a single-line string in code.