SQL Formatter

Beautify and minify SQL queries. Configure keyword case, identifier case, indent width. Supports SELECT, INSERT, UPDATE, CREATE and all major SQL dialects.

1.0.0
Version
Auth
Batch

About SQL Formatter

Pasted SQL is the most reliably unreadable form of code. A query pulled from an application log lands as one wrapped line, a query copied from Slack comes with random capitalisation, and the query generated by an ORM is technically correct but visually unparseable. The desktop options (DBeaver, DataGrip, IntelliJ) all have formatters, but firing one up just to clean a 30-line query someone shared is overkill. Most online SQL formatters either limit output length on the free tier, lock dialect-specific behaviour behind a paid plan, or insist on a signup.

This SQL formatter reformats SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER and the rest with proper line breaks, indentation and clause alignment. Configure keyword case — UPPERCASE, lowercase, or Capitalized (each in turn matches a different style guide; pick the one your team uses). Configure indent width from 1 to 8 spaces. Optionally strip comments if you're about to embed the query in an application string. The minify action collapses everything to one line with semicolons preserved — useful for embedding in a JSON config, copying into a one-liner shell command, or stuffing into a database client where multi-line input is awkward. A statement-type analysis panel tells you what kind of statements your input contains — useful for sanity-checking before running anything destructive. Works with MySQL, PostgreSQL, SQL Server, SQLite, Oracle and most ANSI SQL flavours.

Use it to clean up an ORM-generated query for review, format a query before pasting into a pull-request description, minify a SQL string for embedding in code, normalise whitespace before diffing two queries, or just make a single-line monstrosity readable before debugging. Inputs up to 1 MB — enough for any sane query including ones with large IN lists.

SQL Formatter Use Cases

  • Cleaning up an ORM-generated query before pasting into a code review
  • Normalising whitespace and case before diffing two SQL queries side by side
  • Embedding a query in JSON config or shell one-liner via the minify action
  • Standardising team SQL style by running shared queries through one formatter
  • Making a single-line log-pulled query readable for debugging a slow query
  • Stripping comments from a SQL string before embedding it in application code
  • Formatting a query to match a style guide (uppercase keywords vs lowercase)

SQL Formatter Features

  • Beautifies SQL with proper indentation, line breaks and clause alignment for SELECT/INSERT/UPDATE/DELETE/CREATE/ALTER
  • Minify action collapses to one line with semicolons preserved — handy for embedding in JSON config or shell one-liners
  • Keyword case configurable — UPPERCASE (canonical), lowercase (modern), or Capitalized (legacy style guides)
  • Indent width adjustable from 1 to 8 spaces so the output matches your codebase or style guide
  • Optional comment stripping (-- and /* */) for cleaning queries before embedding in application code
  • Statement-type analysis panel surfaces what's in your input (SELECT vs INSERT vs DELETE) — handy before running destructive SQL
  • Works on MySQL, PostgreSQL, SQL Server, SQLite and Oracle dialects via the underlying sqlparse engine

How to Use SQL Formatter

Paste your SQL

Drop a query, a stored procedure, a migration script or anything else SQL-ish (up to 1 MB) into the input textarea. Multi-statement input separated by semicolons is handled — each statement formats independently.

Pick keyword case and indent

UPPERCASE is the conventional choice for keywords (SELECT, FROM, WHERE); lowercase matches the modern style of some teams; Capitalized is occasionally used for legacy systems. Indent width 2 or 4 spaces is typical.

Optional — strip comments

Tick strip_comments if you're about to embed the query in code where line and block comments would be noise. Leave it off if comments contain useful context (column explanations, optimization notes) you want to keep.

Click Format

The result panel shows the beautified SQL plus a minified one-line version, original and formatted lengths in characters, and a statement-type analysis (SELECT count, INSERT count, UPDATE count, DELETE count) so you can spot a destructive statement before running it.

Copy the version you need

Two copy buttons — one for the beautified multi-line version (paste into a SQL editor, code review, or docs), one for the minified single-line version (embed in JSON, shell, or anywhere multi-line SQL is awkward).

SQL Formatter FAQ

Yes — to a stateless serverless function for the format pass, then discarded immediately. Nothing is logged to durable storage. SQL queries often reference production table names and embedded values; for queries containing live PII or schema you'd rather not transmit, sqlparse (the underlying library) is on PyPI and runs locally.

MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, Oracle (PL/SQL with caveats) and most ANSI SQL flavours. The formatter is structure-based — it understands keywords, operators, identifiers and clauses without needing a dialect declaration. Very dialect-specific syntax (PostgreSQL DO blocks, T-SQL nested CTEs) sometimes ends up with conservative formatting; raise the indent width or use a dialect-aware DBeaver formatter for those edge cases.

Beautify produces a multi-line, indented, readable version with clauses on separate lines (SELECT ... FROM ... WHERE ...). Minify collapses everything to a single line with single-space whitespace and semicolons preserved — the right format for embedding SQL in a JSON config value, a shell one-liner, or a code file where you don't want multi-line strings.

1 MB. This comfortably covers any single query including ones with very large IN lists (tens of thousands of literal values) and most migration scripts. For truly large multi-statement scripts (a schema dump with hundreds of CREATE TABLE statements), format in chunks or use sqlparse in a local script.

No — formatting is whitespace and case only. Identifier case is preserved by default (a column named `userID` stays `userID`), keyword case is altered if you set it explicitly, comments are preserved unless you tick strip_comments. The SQL is semantically identical to the input; only the layout changes.

Lightly. The formatter is permissive — it accepts and lays out any input that looks roughly like SQL, even if syntactically wrong. For strict validation, run the formatted output through your actual database's EXPLAIN or your linter (sqlfluff, sql-formatter-rs). The formatter's analysis panel can spot statement types but not malformed expressions.

It flags DELETE, UPDATE, DROP, TRUNCATE counts in the analysis panel, so you can see at a glance whether the input you formatted contains any of these before you paste the result into a production console. That said, the formatter cannot understand transactional context — a DELETE with a WHERE clause that's too broad still shows as one DELETE statement. Eyeballing the WHERE is still on you.

Try an example:

Input SQL

SQL Formatter Tutorial

What This Does

Pastes in messy single-line SQL, produces readable multi-line SQL with consistent indentation and uppercase keywords. Also produces a minified one-line version for embedding in source code.

Powered By

The battle-tested sqlparse library — same parser used by Django's DB migrations tooling, DBeaver, and many SQL IDEs.

Common Use Cases

  • Clean up generated SQL from an ORM log before sharing with a colleague
  • Convert IDE-copied SQL to something readable in a code review
  • Minify a pretty SQL for embedding in a single-line string literal
  • Enforce house style (uppercase keywords, 2-space indent) on a pile of queries

Options

  • Keyword case — normalize SELECT vs select vs Select
  • Identifier case — optionally force table/column names to a case (leave unchanged if data has quoted identifiers)
  • Indent width — 1 to 8 spaces
  • Strip comments — remove -- line and /* block */ comments

Dialect Support

sqlparse is a non-validating parser — it formats based on lexical structure, not a dialect's grammar. That means it works with MySQL, PostgreSQL, SQL Server, SQLite, Oracle, and most extensions (window functions, CTEs, JSON operators) without fuss. It does NOT catch syntax errors — that's by design.

Limits

Max input size 1 MB. Don't paste entire dumps — use mysql -p's built-in pretty-printer for those.