UseToolSuite UseToolSuite

SQL Formatter

Format and beautify SQL queries with proper indentation and uppercase keywords, or minify them. Supports SELECT, JOIN, WHERE, GROUP BY, and more. 

Formatted SQL will appear here...

SQL formatting conventions across databases

SQL formatting styles vary across database platforms and teams. Most style guides agree on uppercase keywords (SELECT, FROM, WHERE, JOIN), consistent indentation for sub-clauses, and placing each column on its own line for complex queries. PostgreSQL developers tend to use lowercase keywords with 4-space indentation, while Oracle shops prefer uppercase with 2-space indentation. The critical principle is consistency within your codebase — pick a style and enforce it. This formatter supports multiple SQL dialects including standard SQL, PostgreSQL, MySQL, T-SQL, and PL/SQL.

Why formatted SQL matters for code review

Unformatted SQL makes code reviews significantly harder. A single-line query like SELECT a.id, b.name FROM users a JOIN orders b ON a.id = b.user_id WHERE a.active = 1 AND b.total > 100 ORDER BY b.created_at DESC LIMIT 50 obscures logic and makes it easy to miss issues. Properly formatted, each clause is visible at a glance: missing indexes become obvious, join conditions are easy to verify, and WHERE clause logic is clear. Teams that enforce SQL formatting see fewer bugs in data queries and faster onboarding for new developers.

Formatting CTEs and JOINs for reviewability

Common table expressions are the biggest readability win in modern SQL: name each step of a transformation (WITH active_users AS (...), recent_orders AS (...)) instead of nesting subqueries three levels deep. Format each CTE’s body with full indentation, and keep the final SELECT short — reviewers then read your query as a pipeline. For JOINs, put each JOIN on its own line with its ON condition indented beneath it, and join on explicit column equality before adding filters; mixing join conditions into the WHERE clause works for inner joins but silently changes semantics for outer joins.

The keyword casing debate, settled practically

UPPERCASE keywords (SELECT, FROM, WHERE) with lowercase identifiers is the convention this formatter applies and the one most style guides recommend: keywords become visual anchors that structure the query at a glance, exactly like syntax highlighting that survives being pasted into an email, a ticket, or a log. The counter-argument — that highlighting makes casing redundant — fails everywhere SQL travels as plain text, which in practice is most places SQL travels.

One query, one shape: team standardization

Formatting pays off most when it’s uniform across a codebase: diffs shrink to real changes, review comments stop relitigating style, and copy-pasted query fragments compose cleanly. Use this tool for ad-hoc work and one-off cleanups; for repositories of SQL (dbt projects, migration folders), add an automated formatter/linter such as sqlfluff or pgFormatter to CI so the style is enforced, not requested. Adopt the formatter’s defaults wherever possible — custom configurations are maintenance debt.

Formatting as a debugging instrument

A query that returns wrong results often confesses under formatting: the OR that isn’t parenthesized, the join condition hiding in WHERE, the correlated subquery referencing the wrong alias. Reformatting forces every clause onto its own line where these mistakes become visible. It’s the SQL equivalent of rubber-duck debugging — and it’s why formatting belongs before asking a colleague to look at the query.

SQL Formatter Powered by UseToolSuite — free browser tools

Last updated Built and maintained by Necmeddin Cunedioglu How tools are tested

How helpful was this tool?

Click to rate

Key Concepts

JOIN

An SQL clause that combines rows from two or more tables based on a related column. Types include INNER JOIN (only matching rows), LEFT JOIN (all left table rows + matching right), RIGHT JOIN (all right table rows + matching left), and FULL OUTER JOIN (all rows from both tables). JOINs are essential for querying normalized relational data.

Subquery

A SELECT statement nested inside another SQL statement (in WHERE, FROM, SELECT, or HAVING clauses). Subqueries allow complex filtering and derived calculations. Correlated subqueries reference the outer query and execute once per outer row; non-correlated subqueries execute independently and can often be rewritten as JOINs for better performance.

Frequently Asked Questions

Which SQL dialects does this formatter support?

The formatter handles standard SQL syntax that is common across most database systems including MySQL, PostgreSQL, SQLite, SQL Server, and Oracle. Dialect-specific extensions may not format perfectly, but standard SELECT, INSERT, UPDATE, and DELETE queries work well.

Does the formatter uppercase SQL keywords automatically?

Yes. The formatter converts SQL keywords like SELECT, FROM, JOIN, WHERE, GROUP BY, and ORDER BY to uppercase. This follows the widely adopted SQL style convention that makes queries easier to read by visually separating keywords from table and column names.

Can I format stored procedures or DDL statements?

The formatter is optimized for DML queries (SELECT, INSERT, UPDATE, DELETE). DDL statements like CREATE TABLE work for basic formatting, but complex stored procedures with procedural logic (IF/ELSE, loops) may not format as cleanly.

Does the minifier remove SQL comments?

Yes. The SQL minifier removes both single-line comments (--) and multi-line comments (/* */) along with unnecessary whitespace. This produces a compact single-line query suitable for use in application code or logging.

Should commas go at the start or the end of lines in a SELECT list?

Trailing commas (after each column) read like prose and are the more common house style; leading commas (before each column) make adding or removing a column a one-line diff and prevent the classic missing-comma error at the end of a list. Teams that review SQL in version control often prefer leading commas precisely for the cleaner diffs — pick one and enforce it consistently.

How should I format a long WHERE clause with many conditions?

One condition per line, with the AND/OR operator starting each line rather than ending the previous one. Leading operators make the logic scannable top-to-bottom and stop a dropped AND from hiding at a line end. Parenthesize every mixed AND/OR group explicitly — relying on precedence is the source of subtly wrong result sets.

Troubleshooting & Technical Tips

Ambiguous column name error: Column ambiguity in JOIN queries

When joining multiple tables with JOIN, if both tables contain a column with the same name, the database throws an "ambiguous column name" error. Solution: prefix every column reference with the table name or alias: write u.id (FROM users u) instead of just id. The formatter does not fix such semantic errors, but it makes the query readable so you can identify the issue more easily.

Syntax error at or near "GROUP": Incorrect GROUP BY order

SQL clause ordering is strict: SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT. Placing GROUP BY before WHERE or using HAVING without GROUP BY produces a syntax error. The formatter does not automatically correct keyword ordering; it only applies indentation to the existing order. Fix the clause ordering in your query to comply with the SQL standard, then run the formatter.

Subquery parsing error: Parenthesis mismatch in nested SELECT statements

In complex subqueries (nested SELECT), when opening and closing parenthesis counts do not match, the formatter may produce incorrect indentation or fail to parse. Verify that each subquery is properly closed within its own set of parentheses. Pay special attention to IN (SELECT ...), EXISTS (SELECT ...), and FROM (SELECT ... ) AS subq constructs to ensure inner queries are fully closed.

SQL keywords inside string literals are incorrectly formatted

The formatter may detect SQL keywords like SELECT and FROM inside single-quoted ('') string values and convert them to uppercase. For example, the word select in WHERE message = 'select your option' may be affected. This does not break query logic but does change string content. After formatting, check that string literal values have been preserved in their original form.

Related Guides

SQL vs NoSQL: Which Database Architecture to Choose?

A comprehensive guide comparing SQL (Relational) and NoSQL databases. Understand their structures, scaling capabilities, and use cases.

Related Tools

JSON Formatter & Validator

Format & Convert Tools

HTML Formatter

Format & Convert Tools

JSON ↔ YAML Converter

Format & Convert Tools
Embed this tool on your site

Paste this snippet into any HTML page or blog post to embed a live, fully working copy of SQL Formatter. Free for any use.