Does formatting change what the SQL query does?

No. Formatting only changes whitespace, indentation, and keyword casing — it does not alter the logic, table names, column names, values, or execution plan of the query.

Which SQL dialects are supported?

Standard SQL (ANSI), MySQL, PostgreSQL, SQLite, T-SQL (Microsoft SQL Server), and BigQuery. Dialect selection affects identifier quoting (e.g., backticks for MySQL, double quotes for PostgreSQL) and some keyword handling.

Is my SQL query sent to a server?

No. All formatting is done locally in your browser using the sql-formatter JavaScript library. Your queries never leave your device.

When would I use Minify mode?

Minify mode collapses a multi-line query into a single line. This is useful when embedding SQL in application code as a string literal, sending queries via API, or reducing whitespace in log output.

Why does formatting split my query across many lines?

The formatter places each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY) on its own line and indents sub-expressions. This is the widely accepted style for readable SQL — it makes long queries much easier to scan and debug.

SQL Formatter

Format and beautify SQL queries with proper indentation and uppercase keywords. Supports MySQL, PostgreSQL, SQLite, T-SQL, and BigQuery. All processing is done locally in your browser — nothing is uploaded.

Last updated: April 2026

SQL input

Formatted SQL

What it does

Multi-dialect support

Format SQL for MySQL, PostgreSQL, SQLite, T-SQL (SQL Server), BigQuery, and standard ANSI SQL — each dialect handles quoting and keywords correctly.

Keyword uppercasing

Automatically converts reserved words like SELECT, FROM, WHERE, JOIN, and GROUP BY to uppercase for consistent, readable style.

Minify mode

Collapse formatted SQL into a single compact line — useful for embedding queries in code strings or reducing payload size.

Browser-side only

Formatting runs entirely in your browser using the sql-formatter library. No query data is sent to any server.

How to use SQL Formatter

1
Paste your SQL query
Enter any SQL query in the input field — SELECT, INSERT, UPDATE, CREATE TABLE, stored procedures, or complex multi-join queries all work.
2
Choose a dialect
Select your target database: Standard SQL, MySQL, PostgreSQL, SQLite, T-SQL (SQL Server), or BigQuery. Each dialect affects quoting style and keyword handling.
3
Select Format or Minify
Choose Format to pretty-print with indentation and uppercase keywords. Choose Minify to collapse the query to a single line.
4
Adjust indent size
Pick 2 or 4 spaces for indentation. Applies in Format mode only — output updates instantly.
5
Copy or download
Use the Copy button to copy the formatted SQL to your clipboard, or Download to save it as a .sql file.

Technical details

Formatting library	sql-formatter (v15)
Supported dialects	Standard SQL, MySQL, PostgreSQL, SQLite, T-SQL, BigQuery
Keyword case	Uppercase (SELECT, FROM, WHERE, …)
Indent options	2 spaces or 4 spaces
Processing location	Entirely in your browser — nothing is uploaded

SQL formatting conventions — the standard style that most teams adopt

SQL has no official formatting standard, but a widely adopted set of conventions has emerged across the industry. Understanding these conventions helps you write SQL that is immediately readable to any developer.

Keyword casing: the dominant convention is ALL CAPS for SQL reserved words (SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, INSERT, UPDATE, DELETE). This visually separates the SQL structure from table names, column names, and values. Some teams use lowercase keywords in ORMs and application code, but uppercase is standard in data engineering, analytics, and database administration.

One clause per line: each major clause starts on its own line. The columns in a SELECT list each go on their own indented line when there are more than two or three. This makes it easy to add or remove columns, comment out a single column, or scan for a specific field without reading a dense single-line query.

Join indentation: JOINs are typically written at the same indent level as FROM, with the ON condition indented one level further. Each JOIN starts on a new line, making the join chain scannable.

Subqueries: inline subqueries (in FROM, WHERE, or SELECT) are indented and wrapped in parentheses aligned with the surrounding structure. Named CTEs (WITH clauses) are preferred over deeply nested subqueries for readability.

Aliases: table aliases are typically short (one or two letters) and consistent within a query. Column aliases in SELECT use AS and are often quoted when they contain spaces or match reserved words.

SQL dialect differences — what changes between MySQL, PostgreSQL, and SQL Server

Standard SQL (ANSI SQL) defines the core syntax, but every major database engine extends and modifies it. Knowing the key differences prevents errors when moving queries between systems.

Identifier quoting: MySQL uses backticks (\`table_name\`) to quote reserved words used as identifiers. PostgreSQL and SQLite use double quotes ("table_name"). SQL Server uses square brackets ([table_name]) or double quotes. ANSI SQL uses double quotes. This is the most common cause of cross-dialect syntax errors.

String concatenation: Standard SQL and PostgreSQL use the || operator. MySQL uses the CONCAT() function (|| is a logical OR in MySQL by default, though it can be changed). SQL Server uses +.

LIMIT vs TOP vs FETCH: MySQL, PostgreSQL, and SQLite use LIMIT n (with optional OFFSET). SQL Server uses TOP n at the start of the query (pre-2012) or FETCH FIRST n ROWS ONLY (SQL Server 2012+). BigQuery uses LIMIT n like MySQL.

Auto-increment primary keys: MySQL uses AUTO_INCREMENT. PostgreSQL uses SERIAL or GENERATED ALWAYS AS IDENTITY. SQLite uses INTEGER PRIMARY KEY (which auto-increments). SQL Server uses IDENTITY(1,1).

Date functions: date handling differs significantly. GETDATE() in SQL Server, NOW() in MySQL and PostgreSQL, CURRENT_TIMESTAMP in ANSI SQL. Date arithmetic syntax also varies — adding days uses DATEADD() in SQL Server vs interval syntax in PostgreSQL.

CTE support: Common Table Expressions (WITH clauses) are supported in PostgreSQL, SQL Server, MySQL 8+, SQLite 3.35+, and BigQuery. MySQL 5.7 and older do not support CTEs.

Frequently Asked Questions

Does formatting change what the SQL query does?: No. Formatting only changes whitespace, indentation, and keyword casing — it does not alter the logic, table names, column names, values, or execution plan of the query.
Which SQL dialects are supported?: Standard SQL (ANSI), MySQL, PostgreSQL, SQLite, T-SQL (Microsoft SQL Server), and BigQuery. Dialect selection affects identifier quoting (e.g., backticks for MySQL, double quotes for PostgreSQL) and some keyword handling.
Is my SQL query sent to a server?: No. All formatting is done locally in your browser using the sql-formatter JavaScript library. Your queries never leave your device.
When would I use Minify mode?: Minify mode collapses a multi-line query into a single line. This is useful when embedding SQL in application code as a string literal, sending queries via API, or reducing whitespace in log output.
Why does formatting split my query across many lines?: The formatter places each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY) on its own line and indents sub-expressions. This is the widely accepted style for readable SQL — it makes long queries much easier to scan and debug.