SQL Formatter & Beautifier

Format and beautify SQL queries with proper indentation, keyword uppercasing, and line breaks.

Free to use. Runs in your browser.

Paste a SQL query and click Format to apply consistent indentation, uppercase keywords, and line breaks. Supports PostgreSQL, MySQL, SQL Server, and Oracle syntax.

Use it to turn one-line queries into readable clauses before debugging, review, or optimisation.

Input SQL

Why Formatted SQL Matters

SQL is one of the most forgiving languages when it comes to whitespace. A query that works perfectly as one enormous line also works formatted across 20 lines. But the person reading that query, you, six months from now, will strongly prefer the formatted version.

Formatted SQL makes the structure visible. You can see the SELECT clause at a glance, spot which tables are JOINed, understand the WHERE conditions, and verify the GROUP BY columns. With everything on one line, you're scrolling horizontally and guessing at intent.

This formatter takes messy SQL (pasted from logs, generated by ORMs, or squished into a single line) and produces clean, readable SQL. It handles SELECT, INSERT, UPDATE, DELETE, and CREATE statements: keywords are uppercased, and major clauses each start on a new line. Paste, format, understand.

SQL Formatting Conventions

Element	Convention	Example
Keywords	UPPERCASE	SELECT, FROM, WHERE, JOIN
Table/column names	lowercase or snake_case	users, first_name, order_id
Major clauses	New line each	SELECT ... FROM ... WHERE ... ORDER BY
Column lists	One per line (for readability)	id,\n name,\n email
JOINs	New line, indented ON clause	JOIN orders\n ON users.id = orders.user_id
Subqueries	Inner clauses formatted; no nesting-depth indent	WHERE id IN (SELECT ... FROM ...)

What this means for you: There's no one "correct" SQL formatting standard, but the conventions above are the most widely used. The key is consistency within your project. Pick a style and apply it everywhere.

SQL Writing Best Practices

Never use SELECT *

SELECT * fetches every column, including ones you don't need. It slows queries, breaks when columns are added, and makes code harder to understand. Always list the specific columns you need.

Use table aliases consistently

In multi-table queries, alias every table (users u, orders o) and qualify every column (u.name, o.total). This prevents ambiguous column errors and makes it clear where each column comes from.

Comment complex logic

A complex WHERE clause or subquery deserves a comment explaining the business logic. SQL comments use -- for single-line or /* */ for multi-line. Future you will appreciate it.

Use parameterised queries

Never concatenate user input into SQL strings. Use parameterised queries (prepared statements) to prevent SQL injection. Every ORM and database driver supports them natively.

SQL Dialect Differences

Feature	MySQL	PostgreSQL	SQL Server
Limit rows	LIMIT 10	LIMIT 10	TOP 10
String concat	CONCAT(a, b)	a \|\| b	a + b
Auto-increment	AUTO_INCREMENT	SERIAL	IDENTITY(1,1)
Upsert	ON DUPLICATE KEY	ON CONFLICT	MERGE
Identifier quotes	`backticks`	"double quotes"	[brackets]

This formatter handles standard SQL syntax. Dialect-specific keywords format correctly, but always test formatted SQL against your actual database before running in production.

Worked Example: Debugging ORM SQL

Jack sees a slow request in a Rails app. The log contains one long SQL query generated by the ORM. It joins users, orders, order_items, and products, then filters by date.

1. Format the log query

Each JOIN moves to its own line. The WHERE clause is split into separate conditions, making the date range and status filter visible.

2. Spot the missing filter

The formatted query reveals no tenant_id condition. The query is scanning rows for all customers instead of one account.

3. Check selected columns

The SELECT list includes several columns that the page never uses. Listing columns clearly makes the extra payload easy to remove.

4. Run an explain plan

Formatting helps him read the query, but the database plan confirms whether indexes are used and where time is spent.

What Formatting Helps You See

Query area	Formatting clue	Possible issue
SELECT list	Many columns or SELECT *	Fetching data the app does not use
JOIN clauses	Several joins without clear aliases	Ambiguous column names or accidental row multiplication
WHERE filters	Long AND/OR chain	Missing parentheses can change logic
GROUP BY	Columns do not match selected aggregates	Different dialects may reject or reinterpret the query
ORDER BY	Sorting on unindexed or computed expressions	Slow sorts on large result sets

SQL Safety Notes

Formatting is not validation

A query can look tidy and still fail. Table names, column names, permissions, and dialect-specific syntax must be checked by the database engine.

Parameterise user input

Formatting a query does not make string concatenation safe. Use prepared statements or ORM parameters when values come from users.

Review destructive statements

DELETE, UPDATE, DROP, and TRUNCATE deserve extra attention. Check the WHERE clause and run inside a transaction when your database supports it.

Hide sensitive literals

Queries copied from logs can contain email addresses, account IDs, or tokens. Remove sensitive values before sharing formatted SQL with anyone else.

SQL Review Checklist

Read the FROM clause first. Confirm the query starts from the table you expect.
Check every JOIN condition. A missing ON clause or weak join can multiply rows.
Scan WHERE before running writes. UPDATE or DELETE without the right filter is the classic dangerous SQL mistake.
Look for SELECT *. Listing columns makes output clearer and can reduce unnecessary data transfer.
Run EXPLAIN for performance questions. Formatting helps humans read the query. The execution plan shows what the database will actually do.

Related Tools

JSON Formatter

Format JSON query results

CSV to JSON Converter

Convert SQL exports to JSON

Text Diff Checker

Compare query versions

Regex Tester

Test patterns for LIKE/REGEXP

Hash Generator

Hash passwords for storage

XML Formatter

Format XML data exports

How to use this tool

Paste your SQL query into the input field

Click Format SQL to beautify with proper indentation

Copy the formatted output for your codebase

Common uses

Formatting ORM-generated SQL for debugging
Cleaning up single-line SQL for code reviews
Beautifying log-extracted queries for analysis
Standardising SQL style across a development team

Share this tool

Frequently Asked Questions

What does this SQL formatter do?

It takes messy SQL (single-line, no indentation, inconsistent casing) and reformats it with proper indentation, UPPERCASE keywords, and line breaks at major clauses. The result is clean, readable SQL that's easy to review and debug.

Does this support all SQL dialects?

It handles standard SQL syntax that's common across MySQL, PostgreSQL, SQLite, and SQL Server. Dialect-specific extensions (window functions, CTEs, RETURNING clauses) will format but keyword highlighting may vary.

Does it validate my SQL?

No, this is a formatter, not a validator. It doesn't check syntax, table names, or column references. It reformats whatever you give it. Use your database client or a linter for validation.

Is my SQL sent to a server?

No. All formatting happens locally in your browser using JavaScript string manipulation. Your queries never leave your device, important if you're working with production SQL.

Why should I uppercase SQL keywords?

It's a widely-adopted convention that makes SQL structure immediately visible. SELECT, FROM, WHERE, JOIN stand out from table and column names. Most SQL style guides recommend uppercase keywords for readability.

Can it format complex queries with subqueries?

Partially. Major clauses (SELECT, FROM, WHERE, the JOIN variants, GROUP BY, ORDER BY, UNION) each start on a new line, and AND/OR conditions are indented. Subquery bodies and CTE bodies are not indented as a nested block; they receive the same clause-break treatment as the outer query. The formatter does not track parenthesis depth.

Does it handle CREATE TABLE and DDL statements?

Yes. CREATE, ALTER, DROP, and INDEX statements are supported. Keywords are uppercased and formatted with appropriate line breaks.

What about Common Table Expressions (CTEs)?

The WITH keyword is not in the formatter's clause list, so it does not automatically start a new line. SQL keywords inside the CTE body (SELECT, FROM, WHERE, and so on) are uppercased and get clause line breaks, but the overall CTE structure is not given nesting-aware indentation.

Can I minify SQL instead of formatting it?

This tool only formats (beautifies) SQL. To minify, you'd strip all extra whitespace and newlines. For SQL, minification is rarely needed, unlike CSS or JavaScript, SQL query size doesn't affect network performance.

How should I format long SELECT lists?

Best practice: one column per line. This makes it easy to add, remove, or comment out columns, and produces cleaner diffs in version control. This formatter puts major clauses on new lines.

Does it handle stored procedures?

Basic procedure syntax will format, but complex procedural extensions (PL/pgSQL, T-SQL control flow) may not indent perfectly. The formatter focuses on DML (SELECT, INSERT, UPDATE, DELETE) and DDL statements.

Why are parameterised queries important?

Never concatenate user input into SQL strings, that's how SQL injection happens. Use parameterised queries (prepared statements) where the database driver handles escaping. Current ORMs and database drivers support them.

Can I format queries copied from database logs?

Yes. Log output is often one long line with placeholders or literal values. Formatting makes joins, filters, and ordering easier to inspect before you explain the query plan.

Does formatting change query performance?

No. Database engines ignore whitespace between SQL tokens. Formatting changes readability, not the execution plan, index choice, or returned rows.

Should I format generated ORM SQL?

Yes, when you need to understand what the ORM sent to the database. Formatting generated SQL can reveal accidental cartesian joins, missing filters, or SELECT * output.

How do I handle very long IN lists?

Long IN lists become easier to read when values are grouped across lines, but they may still be a performance smell. For large lists, consider a temporary table, join, or parameter array depending on your database.

Can I format SQL with comments?

Yes. Both single-line comments (--) and block comments (/* */) are left exactly as written. Keywords and clause breaks inside comment text are not altered. For complex queries, comments are a good place to explain business logic, but avoid putting secrets, account IDs, or credentials in them.

Can I format migration scripts?

Yes. CREATE TABLE, ALTER TABLE, index creation, and seed INSERT statements can all be formatted for review. Run the formatted script in a safe environment before applying it to production.

Why does formatted SQL help code review?

Readable clauses make it easier to see selected columns, joins, filters, and ordering. Reviewers can spot missing WHERE clauses or unexpected joins without scanning one long line.

Does this formatter quote identifiers?

No. It preserves the identifiers you provide. If your database needs backticks, double quotes, or brackets, keep those in the input query.

Results are for general informational purposes only and should be checked before use. They are not professional advice. See our Disclaimer and Terms of Service.