SQL Formatter

Formatting profile:

Start with a team-friendly profile, then refine the visible style controls.

SQL dialect:

Choose the database syntax that will receive the formatted artifact.

SQL source:

Paste up to 250,000 characters. Comments, quoted identifiers, and string literals are protected while statements are analyzed.

Keyword case:

Uppercase is common in review artifacts; preserve follows the supplied keyword case where the engine supports it.

Indent width:

Use 2 or 4 for most SQL review workflows.

spaces

Data type case:

Preserve is neutral; choose a case only when the destination style requires it.

Function case:

Preserve avoids recasing vendor-specific or user-defined functions.

Logical operator line break:

Before keeps each condition's connector visible at the start of its line.

Lines between statements:

One line is the compact default; add separation for review documents.

lines

Expression width:

Lower widths break parenthesized expressions sooner.

chars

Use tabs:

Off uses the visible indent width; on emits tabs.

Dense operators:

Off retains review-friendly spaces around arithmetic and comparison operators.

Semicolon on new line:

Off leaves a terminator at the end of its statement line.

{{ semicolon_new_line ? 'Separate terminator line' : 'End-of-statement terminator' }}

{{ values.formatted_sql }}

#	Statement	Input shape	Output shape	Review note	Copy
{{ row.index }}	{{ row.type }}	{{ row.input_shape }}	{{ row.output_shape }}	{{ row.note }}

Check	Status	Detail	Copy
{{ row.check }}	{{ row.status }}	{{ row.detail }}

SQL that runs correctly can still be difficult to review. Long clauses hide join conditions, inconsistent indentation blurs nesting, and a compact sequence of statements makes it easy to miss where one change ends and the next begins. Formatting adds a visual hierarchy without changing the intended query.

The database dialect matters because SQL is a family of related languages rather than one perfectly uniform grammar. PostgreSQL casts, MySQL quoting, T-SQL batches, Oracle PL/SQL blocks, and warehouse-specific clauses do not all parse the same way. A layout chosen under the wrong dialect may look plausible while mishandling vendor syntax.

Dialect: The grammar and keywords expected by the destination database.
Statement: A complete SQL operation, commonly separated from the next operation by a semicolon.
Protected text: String literals, quoted identifiers, and comments whose contents must not be recased or split as ordinary SQL.

Consistent casing and line breaks help humans compare queries, discuss reviews, and spot suspicious structure. They do not prove that names exist, data types match, permissions are sufficient, or the statement is safe to execute. Formatting should therefore happen before database validation, not in place of it.

How to Use This Tool:

Choose the receiving database syntax before adjusting style so the formatter reads the SQL in the right grammar.

Choose a Formatting profile and the matching SQL dialect. The review profile is a sensible starting point for ordinary code review.
Paste the SQL or load one SQL or text file. Keep the source within 250,000 characters; local files are limited to 500,000 bytes.
Set the keyword case and indentation. Open Advanced only when the destination style requires different type or function casing, logical-operator placement, statement spacing, tabs, dense operators, or separate semicolon lines.
Read Formatter audit before reusing the output. A fallback engine, unbalanced parentheses, missing protected text, or a procedural-SQL warning needs manual review in the destination database tooling.

Interpreting Results:

Formatted SQL is the layout artifact. The Statement ledger compares input and output shape for each semicolon-delimited statement, while Formatter audit identifies the engine used and checks parenthesis balance and protected-text preservation.

A Pinned runtime status means the selected dialect was handled by the full formatter. Fallback means a conservative local formatter produced a readable preview because the pinned formatter was unavailable or rejected the source. Treat fallback output as a review aid, not as dialect validation.

Line counts and longest-line measurements describe layout change only. More lines can improve reviewability, but neither a larger nor a smaller result is inherently better. Execute or parse the final statement with the intended database or its trusted tooling before deployment.

Technical Details:

SQL formatting is a structure-preserving transformation. Tokens are interpreted under a selected dialect, then whitespace, indentation, casing, and line placement are rewritten around those tokens. Literal values and quoted names must remain data, even when their contents resemble keywords or punctuation.

Transformation Core:

Stage	Rule	Important boundary
Normalize input	Convert carriage-return line endings to line feeds and trim outer whitespace.	Indentation inside the SQL is retained for parsing rather than treated as a result guarantee.
Choose grammar	Apply the selected Standard SQL, database, or warehouse dialect.	A dialect choice guides formatting; it does not connect to or inspect that database.
Format tokens	Apply casing, indentation, logical-operator, expression-width, statement-spacing, operator-spacing, and semicolon rules.	Quoted strings, quoted identifiers, bracketed identifiers, and comments are protected from ordinary token rewriting.
Split statements	Count semicolons only when they occur outside protected text.	A script without a trailing semicolon still yields a final statement and a warning.
Audit output	Compare statement shape, check parentheses outside protected text, and confirm protected segments remain verbatim.	These checks are narrower than a parser, schema check, or database execution plan.

The primary formatter supports Standard SQL plus PostgreSQL, MySQL, MariaDB, SQLite, SQL Server T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, Spark SQL, Trino or Presto, and IBM DB2. When that formatter cannot produce a result, the fallback protects quoted and commented segments, recognizes a bounded keyword and clause set, and applies conservative line and spacing rules.

Parenthesis balance is calculated outside protected segments. A final balance of zero with no negative running balance indicates matched opening and closing parentheses in that limited scan. It cannot detect a misplaced clause, a wrong function signature, a missing identifier, or procedural delimiters whose meaning depends on the database client.

Privacy and Accuracy Notes:

SQL text and loaded files are processed in the browser and are not sent to a database service. The output can still contain table names, comments, literals, credentials, or production identifiers, so remove sensitive content before sharing formatted files or review exports.

No formatting result certifies correctness or safety. Pay special attention to dynamic SQL, stored procedures, triggers, vendor extensions, delimiter directives, and scripts whose semicolons do not represent ordinary statement boundaries.

Worked Example:

A PostgreSQL reporting query contains a string such as 'order by newest', a comment, two joins, and several conditions. Choosing PostgreSQL and review formatting can recase real keywords and break clauses across lines while leaving the quoted phrase and comment unchanged. If the audit reports the pinned runtime, balanced parentheses, and preserved protected text, the result is ready for a final PostgreSQL parse or review—not automatic execution.

References:

SQL Formatter documentation and configuration options, sql-formatter project.
PostgreSQL lexical structure, PostgreSQL Global Development Group.
MySQL schema object names, Oracle MySQL Documentation.