Format SQL Online

How to Format SQL Online

1. Paste Your SQL: Drop a raw query, stored procedure, or .sql script into the input editor — single-line ORM output, minified production logs, or copy-pasted notebook cells all work. You can also load a local .sql file.
2. Pick the Dialect: Choose Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server (T-SQL), or Oracle PL/SQL so vendor keywords (RETURNING, backticks, CONNECT BY, [bracketed identifiers]) tokenize correctly. Standard SQL is a safe default for ANSI-compliant queries.
3. Set Indent and Casing (Optional): Choose 2-space or 4-space indent, switch between spaces and tabs, force keywords to UPPERCASE or lowercase, and pick trailing or leading commas. Settings apply uniformly to every statement in the input.
4. Click Format: The indented output appears in the read-only panel on the right. Copy to clipboard, download as a .sql file, or paste back into your editor. Processing runs entirely in your browser — your SQL never leaves the page.

Why Format SQL?

SQL formatting is whitespace-only rewriting: a parser splits the query into tokens (keywords, identifiers, literals, operators), then re-emits them with consistent indentation, line breaks, and keyword casing. The result is byte-different but semantically identical — the database produces the exact same execution plan and result set. That zero-risk property is why formatting belongs in every SQL workflow.

• Code review hygiene — Inconsistent whitespace creates noisy diffs that hide the actual change. Formatting both versions to the same style before review surfaces real edits and shrinks PR turnaround. Pair with Text Diff to compare two formatted queries side by side.
• Debugging nested logic — A 400-character single-line query hides the JOIN tree and WHERE chain. Indented output makes subquery boundaries, CASE branches, and correlated references jump out, often turning a half-hour bug hunt into a 30-second scan.
• Reading ORM output — Hibernate, SQLAlchemy, ActiveRecord, and Prisma emit functional but unreadable SQL — long aliases, no line breaks, alphabet-soup column lists. Formatting reveals what the ORM is actually sending to the database, which is essential when tuning slow endpoints.
• Dialect migration — Moving a query from MySQL to PostgreSQL or Snowflake to BigQuery? Format with the source dialect first to confirm parsing succeeds, then format with the target to spot syntax that needs rewriting (e.g., AUTO_INCREMENT → SERIAL, LIMIT → TOP, MySQL backticks → double quotes).
• Documentation and runbooks — Wiki pages, ADRs, and on-call runbooks often embed reference queries. A formatted query reads like code in a textbook; an unformatted one reads like noise readers skip.
• Team style enforcement — Agree on one configuration (4 spaces, UPPERCASE keywords, trailing commas) and run every query through it. Removes the "should we capitalize SELECT?" debate from code review forever.

SQL Dialect Quirks at a Glance

Feature	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle PL/SQL	SQLite	Snowflake	BigQuery
Row limit	LIMIT n	LIMIT n	TOP n / OFFSET FETCH	FETCH FIRST n ROWS	LIMIT n	LIMIT n	LIMIT n
Identifier quoting	"col"	`col`	[col]	"col"	"col" or `col`	"col"	`col`
String concat	||	CONCAT() (no || by default)	+ or CONCAT()	||	||	||	CONCAT()
Auto-increment	SERIAL / IDENTITY	AUTO_INCREMENT	IDENTITY(1,1)	sequence + trigger	AUTOINCREMENT	AUTOINCREMENT	GENERATE_UUID() / sequence
Insert returns	RETURNING	LAST_INSERT_ID() after	OUTPUT	RETURNING ... INTO	RETURNING (3.35+)	RETURNING	not supported
Window filter	nested subquery	nested subquery	nested subquery	nested subquery	nested subquery	QUALIFY	QUALIFY
Boolean type	BOOLEAN	TINYINT(1)	BIT	NUMBER(1)	INTEGER (0/1)	BOOLEAN	BOOL

Selecting the matching dialect in the formatter tells the tokenizer which of these to treat as keywords versus identifiers — picking PostgreSQL on a T-SQL query, for example, can cause [bracketed] names to format as array literals.

Formatting Style Reference

Setting	Common choice	When to use the alternative
Keyword case	UPPERCASE	Lowercase if your editor color-codes keywords; mixed teams sometimes settle on lowercase to reduce shift-key fatigue.
Indent	4 spaces	2 spaces for shallow queries that fit on one screen; tabs if the rest of your codebase uses tabs.
Comma placement	Trailing (col1,\n col2)	Leading ( , col2) makes commenting out a single column a one-character change — popular in analytics / dbt teams.
Line breaks	Per clause (SELECT, FROM, WHERE on own lines)	Compact single-line for trivial SELECT 1 smoke tests.
Identifier case	Leave as-is	Lowercase for snake_case codebases; UPPERCASE only if your team enforces it (rare).

The widely cited Simon Holywell SQL Style Guide recommends UPPERCASE keywords plus aligned "river" indentation; Mozilla's data-engineering style guide agrees on UPPERCASE keywords with trailing commas. Both are reasonable defaults — pick one, configure the formatter once, and stop arguing about it.

Frequently Asked Questions

Does formatting change query behavior or execution plan?

No. The formatter only touches whitespace, line breaks, and (optionally) keyword casing. SQL is case-insensitive for reserved words by ANSI standard, so SELECT and select parse identically. Table names, column names, aliases, JOIN conditions, WHERE predicates, and literal values are emitted byte-for-byte. The query optimizer sees the same parse tree, so the execution plan is unchanged. You can format any query without retesting.

Why does the dialect dropdown matter if SQL is "standard"?

Because every major engine extends standard SQL with its own keywords and quoting rules, and the formatter's tokenizer needs to know which set to apply. MySQL uses backticks for identifiers, SQL Server uses square brackets, PostgreSQL uses double quotes plus the :: cast operator. Oracle has CONNECT BY for hierarchical queries; Snowflake has QUALIFY for filtering on window functions; BigQuery uses backtick-quoted fully qualified names like `project.dataset.table`. Picking the wrong dialect can cause those tokens to misparse, producing weird indentation or merged identifiers in the output.

Should keywords be UPPERCASE or lowercase?

It's a style preference — both are valid because SQL keywords are case-insensitive. Traditional style guides (Simon Holywell, Mozilla data engineering, most database vendor docs) prefer UPPERCASE because it visually separates the SQL grammar from your schema. Modern dbt and analytics teams increasingly prefer lowercase because syntax-highlighting editors already color keywords, and lowercase is faster to type. Pick one, configure it as the formatter default, and apply it consistently — the choice matters far less than the consistency.

Trailing commas or leading commas — which is "right"?

Both are fine; the formatter supports both. Trailing commas (col1,\n col2,) read more naturally as English prose. Leading commas ( , col2) make it trivial to comment out a single column during debugging because you only flip the leading character, never need to fix a dangling comma. Analytics and dbt teams often pick leading commas for exactly that debugging convenience; application-code teams usually pick trailing. The formatter will rewrite either direction, so you can experiment.

Should I expand inline subqueries to CTEs?

That's a refactor, not a format — the SQL Formatter intentionally won't rewrite a subquery into a WITH clause because the two forms can produce different query plans on some engines (especially older PostgreSQL where CTEs were optimization fences before version 12). Use a formatter for cosmetic cleanup; use your hands or a dedicated linter (SQLFluff, sqlglot) for structural refactors. A reasonable workflow: format first to see the structure, then manually promote deeply nested subqueries to CTEs.

What's the difference between SQL formatting, linting, and minifying?

Formatting rewrites whitespace and casing for human readability — same tokens, prettier layout. Linting flags style and correctness issues (missing aliases, ambiguous columns, anti-patterns like SELECT * in production code) without modifying the query. Minifying does the opposite of formatting: it strips whitespace to send queries over the wire compactly, mostly useful for embedding SQL in URL parameters or compressed logs. This tool does formatting only; for linting try SQLFluff, and for minifying most editors have a "join lines" command that does the job.

Can I format stored procedures, CTEs, and window functions?

Yes. The parser handles CREATE PROCEDURE / CREATE FUNCTION blocks, BEGIN/END boundaries, variable declarations, IF / WHILE control flow, WITH clauses for CTEs, and window functions including OVER (PARTITION BY ... ORDER BY ...). For best results pick the dialect that matches the procedural syntax — T-SQL for SQL Server, PL/SQL for Oracle — because those two have the most engine-specific constructs.

Is my SQL sent anywhere?

No. Formatting runs entirely in your browser in JavaScript. The page loads once, then your query stays local — no network request, no logging, no retention. Safe for queries that reference production table names, customer columns, or embedded credentials. You can verify by opening DevTools' Network tab while formatting, or by disconnecting from Wi-Fi after the page loads — formatting still works. For related text tools that also run client-side, see JSON Formatter, Text Diff, and JSON to CSV.

How big a query can I paste?

Practically, anything up to a few megabytes formats in well under a second on a modern laptop. Browser memory is the only hard limit — multi-statement dumps in the tens of MB may take a couple of seconds and consume a few hundred MB of RAM. For nightly schema dumps measured in hundreds of MB, split the file first or use a CLI tool like sql-formatter (npm) or sqlfluff (Python) which stream input.