SQL Formatter & Minifier

Beautify or compress SQL across PostgreSQL, MySQL, SQLite, BigQuery, MS SQL, and Standard SQL. Keyword case, indent size, and dialect-aware parsing — all running locally in your browser.

Dialect

Keywords

Indent

Input SQL

Output

About SQL Formatter

This tool parses raw SQL and rewrites it with consistent indentation, aligned clauses, and standardized keyword casing — or collapses it into a single compact line for embedding in code. Everything runs client-side using the open-source sql-formatter library; your queries never leave your browser.

Why does dialect matter?

SQL is a standard on paper, but every major database vendor has extended the language with its own syntax. A one-size-fits-all formatter either rejects valid queries or mangles vendor-specific tokens. Picking the right dialect means the parser recognizes:

PostgreSQL: DISTINCT ON (col), ::type casts, RETURNING, ILIKE, array operators like @>, dollar-quoted strings $$...$$, window frame exclusions.
MySQL / MariaDB: Backtick identifiers `col`, LIMIT offset, count, ON DUPLICATE KEY UPDATE, GROUP_CONCAT, storage engine hints.
SQLite: AUTOINCREMENT (not AUTO_INCREMENT), WITHOUT ROWID, limited ALTER TABLE forms, PRAGMA statements.
BigQuery: Backtick-wrapped `project.dataset.table` references, STRUCT/ARRAY literals, UNNEST, EXCEPT / REPLACE inside SELECT *.
MS SQL (T-SQL): TOP (n) instead of LIMIT, [bracketed] identifiers, OUTPUT clauses, GO batch separators, OFFSET … FETCH NEXT.
Oracle PL/SQL: (+) legacy join syntax, CONNECT BY, sequence .NEXTVAL, MERGE with WHEN MATCHED.
Snowflake: QUALIFY, LATERAL FLATTEN, semi-structured VARIANT access with colons.

When in doubt, start with Standard SQL — it handles the ANSI common core. If your query uses anything vendor-specific, switch to the matching dialect to avoid parse errors.

Format vs Minify

Format (pretty-print) adds line breaks and indentation to make queries auditable — ideal for code reviews, migrations, and documentation. Minify collapses whitespace to produce a single-line version suitable for embedding in source code strings, logs, or URL parameters. The Swap button lets you round-trip: format a minified query to inspect it, then minify it back.

Privacy

Nothing is uploaded. The parser and formatter execute in your browser, so production queries, schema names, and hardcoded values stay on your machine. Safe to use with sensitive SQL you'd never paste into a cloud service.

Frequently Asked Questions

Will formatting change the meaning of my query?

No. Formatting only rewrites whitespace, indentation, and optionally keyword case. The logical query — tables, columns, predicates, joins, subqueries — is preserved exactly. String literals and comments are also left untouched.

Why does my query fail to format?

The parser needs syntactically valid SQL. Common causes: unclosed quotes or parentheses, a dialect mismatch (e.g. trying to format MySQL backticks under Standard SQL), or mid-statement templating placeholders like {{var}}. Try switching dialects, or strip templating tokens before formatting.

Does minify remove comments?

Minify collapses whitespace and newlines. Single-line -- comments become problematic in one-line SQL because they comment out everything until a newline — so they're stripped. Block comments /* … */ are generally preserved but may be removed depending on placement. Review the output before pasting into code.

Can I format a file with multiple statements?

Yes. Separate statements with semicolons and they'll each be formatted independently. This works well for migration scripts, seed files, and multi-statement stored procedure bodies.

Should keywords be uppercase or lowercase?

It's a style preference. Uppercase keywords (SELECT, FROM, WHERE) are the traditional convention and make queries easier to scan because keywords stand out from identifiers. Lowercase is growing in popularity in modern codebases for readability and because editors already syntax-highlight. Pick one and apply it consistently across your project.