SQL Beautifier / Minifier

Reformat or compact common SQL while preserving quoted text and exposing dialect-sensitive limits.

SQL Input

Paste a SQL query, migration snippet, database log query, report query, or copied statement to beautify, minify, and review it.

Characters

Lines

Statements

Joins

Formatting Options

Action

Keyword Case

Output Format

Indent Size

Comma Style

Browser-first formatting

SQL processing runs locally. No query text is sent to a server.

Break before JOIN clausesPut JOIN, LEFT JOIN, INNER JOIN, and related joins on separate lines for easier review.Break AND / OR conditionsPut top-level AND and OR conditions on indented lines after the formatter separates major clauses.Uppercase common functionsConvert functions such as count, sum, coalesce, and cast to uppercase.Remove SQL commentsRemove ordinary line and block comments. MySQL version comments and optimizer-hint comments are preserved because they can affect execution.

Query Structure Preview

A quick breakdown of the query shape based on keyword counts.

SELECT

WHERE

GROUP BY

ORDER BY

INSERT

UPDATE

DELETE

JOIN

SQL Output

Formatted or minified SQL output will appear here.

Formatting does not execute the query, connect to a database, or prove that the output is valid for a particular SQL dialect.

Formatting SQL Without Touching Quoted Data

Whitespace and keyword casing look cosmetic until a formatter changes text inside a string literal, quoted identifier, comment, or stored-function body. The formatting pass protects those lexical regions first, then adjusts the surrounding SQL. That keeps values such as 'a b', semicolons inside strings, and quoted names out of the rewrite rules.

What the Beautifier Changes

Keyword case outside protected strings, identifiers, and comments.
Spacing around common comparison operators and commas.
Line breaks around major clauses and, when selected, JOIN and AND/OR boundaries.
Top-level SELECT-list commas, with leading or trailing comma style.
A small set of common function names when the uppercase-functions option is enabled.

Minifying Is Not SQL Compression

Minification removes formatting whitespace outside protected lexical regions. It does not rewrite expressions, optimize the query plan, shorten identifiers, or change parameter values. Ordinary comments can be removed, but comments with execution meaning such as MySQL /*! ... */ version comments and /*+ ... */ optimizer hints are preserved.

Dialect Boundaries Matter

SQL is not one interchangeable grammar. PostgreSQL has dollar-quoted strings and nested block comments; MySQL uses backtick-quoted identifiers and execution-sensitive comments; SQL Server commonly uses bracketed identifiers; cloud warehouses add their own clauses and functions. The formatter protects several widely seen lexical forms, but it is not a full parser for every vendor grammar. A quote immediately preceded by an odd number of backslashes is rejected because different dialects disagree about whether the backslash escapes that quote.

Review stored procedures, procedural SQL, vendor-specific operators, templated SQL, and migration scripts before replacing source code with formatted output. The structure counters are lexical signals, not syntax validation or query-plan analysis.

Safety Notes for Destructive Statements

DELETE and UPDATE statements are checked one statement at a time for a missing WHERE clause, and DROP/TRUNCATE are called out for review. Those notices cannot understand business intent, triggers, permissions, transactions, or database-specific semantics. Treat them as a visual prompt, not as an approval to run a statement.

A Useful Lexical Reference

PostgreSQL's official lexical-structure documentation is a good concrete example of why a formatter has to distinguish tokens, quoted strings, dollar-quoted strings, special characters, and comments before changing whitespace. Other database engines have their own syntax documentation and should be checked when dialect-specific SQL matters.