SQL Formatter & Beautifier

Paste minified or messy SQL and get properly indented, readable output. Handles subqueries, CASE/WHEN blocks and CTEs. Minify for production. 10 dialects supported.

sql-formatter.tool
Input SQL
Output

What This Formatter Actually Does

Most simple online SQL formatters use find-and-replace on keywords — which breaks on anything complex. This tool uses a token-based approach: it reads the SQL character by character, identifies every token (keywords, strings, identifiers, operators, comments), then rebuilds the query with proper structure. Subqueries inside parentheses get their own indentation level. CASE/WHEN/THEN/ELSE/END blocks are indented correctly. GROUP BY and ORDER BY are treated as two-word units, not split across lines.

Formatting Options

  • Keyword case — UPPERCASE is the SQL standard convention and easiest to read. Lowercase keywords are preferred in some teams (particularly PostgreSQL shops). "Keep original" leaves your case decisions intact.
  • Indent size — 2 spaces is compact and fits more on screen. 4 spaces is the traditional SQL convention and easier to scan visually.
  • Comma position — "Comma after" (col1, col2) is the JavaScript convention but harder to comment out a column. "Comma before" (, col1, col2) is preferred by many SQL developers because commenting out the last column never breaks the syntax.
  • Remove comments — strips both -- line comments and /* block comments */ from the output. Useful when pasting query plans or sharing SQL without internal notes.

Minify

The Minify button compresses the SQL to a single line with minimal whitespace — useful when embedding SQL strings in application code, config files, or API payloads where line breaks would cause issues. The Remove Comments checkbox works with minify too.

Frequently Asked Questions

The dialect selector labels which database the SQL is intended for, but the formatting logic is largely the same across dialects — indentation, keyword placement, and clause structure follow the same SQL standard. Dialect-specific syntax (PostgreSQL dollar-quoting, T-SQL square brackets, MySQL backtick identifiers) is preserved because the tokeniser handles all common quoting styles. The selector exists to document intent and for future dialect-specific formatting rules.
Comma-first style (also called leading commas) places the comma at the start of each line after the first: SELECT id, name becomes SELECT id, name where the comma leads each column after the first. The practical advantage: when you want to comment out the last column, you never break the syntax. In comma-last style, commenting out the last column leaves a trailing comma which causes an error. Many experienced SQL developers prefer comma-first for this reason, particularly in version-controlled queries.
The formatter tracks CASE depth — each CASE adds one indentation level, and END removes it. If your SQL has nested CASE statements (CASE inside a CASE), each level gets its own indent. Check that every CASE in your query has a matching END. An unclosed CASE will cause all subsequent lines to be over-indented. The formatter does not validate SQL — it formats the structure as written.
The formatter handles standard SQL well. For Oracle PL/SQL and SQL Server T-SQL procedural blocks (DECLARE, BEGIN/END blocks, IF statements, WHILE loops), it applies basic indentation but complex procedural structures may not format perfectly. For heavily procedural code, a dedicated PL/SQL or T-SQL formatter will give better results. This tool is optimised for SELECT, INSERT, UPDATE, DELETE, and DDL statements.
No. Formatting only adds or removes whitespace. SQL parsers in all databases treat whitespace identically — a single space, multiple spaces, and a newline are all the same token separator. The formatted query and the original query produce exactly the same execution plan when run against a database. Minification similarly changes nothing about execution.