FC

🗄️ SQL Formatter

Format and beautify SQL queries - capitalises keywords and adds clean indentation

SELECT
  u.id,
  u.name,
  u.email,
  count(o.id) AS order_count,
  sum(o.total) AS total_spent
FROM users u 
LEFT 
JOIN orders o 
ON u.id = o.user_id 
WHERE u.created_at > '2024-01-01' 
  AND u.active = true 
GROUP BY u.id, u.name, u.email 
HAVING count(o.id) > 0 
ORDER BY total_spent desc 
LIMIT 50
Complete Guide

📊 Key Data Points

Keyword capitalization

SELECT, FROM, WHERE, JOIN — capitalizing SQL keywords is the near-universal convention

CTE formatting

WITH clauses (Common Table Expressions) need special formatting — each CTE as a separate named block

Multi-dialect

MySQL, PostgreSQL, SQLite, and SQL Server syntax all supported

SQL Formatter — Beautify and Indent SQL Queries -- Complete USA Guide 2026

Complex SQL queries with multiple JOINs, CTEs, subqueries, and window functions are nearly impossible to read when written as single lines. Proper indentation and keyword capitalization make query structure immediately clear for review and debugging.

This formatter re-indents SQL with consistent formatting. Runs in your browser.

**Long-tail searches answered here:** sql formatter online free, sql query beautifier browser tool, format sql query with indentation no install.

For understanding JOINs visually, use SQL JOIN Visualizer.

🔬 How This Calculator Works

Formats SQL by parsing keywords (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, UNION, CTE, subqueries) and applying consistent indentation and line breaks. Capitalizes SQL keywords. Supports standard SQL, MySQL, PostgreSQL, SQLite, and common SQL extensions. Output is copy-ready for use in your query tool, code, or documentation.

✅ What You Can Calculate

Keyword capitalization

Capitalizes SQL keywords (SELECT, FROM, WHERE, JOIN) consistently — a standard convention that distinguishes keywords from table/column names.

Multi-level indentation

Properly indents subqueries, CTEs (WITH clauses), CASE statements, and nested JOINs — each level gets additional indentation.

CTE formatting

WITH RECURSIVE and regular CTE clauses are formatted with each CTE as a clearly delimited block.

Multi-dialect support

Handles MySQL, PostgreSQL, SQLite, and SQL Server syntax including dialect-specific functions and extensions.

🎯 Real Scenarios & Use Cases

Code review documentation

Paste a complex query into your PR description in formatted form. Reviewers can see the query structure at a glance rather than deciphering a single line.

Debugging query logic

Format a query you copied from your ORM to see what SQL is actually being generated. Indentation reveals the JOIN order and WHERE conditions clearly.

Documentation generation

Format canonical versions of complex queries for your technical documentation or runbook.

Learning SQL

Format example queries from tutorials and documentation to better understand complex SQL patterns like CTEs and window functions.

💡 Pro Tips for Accurate Results

Format before sharing. Always format SQL queries before including them in PRs, Slack messages, or documentation. Unformatted single-line queries are difficult to review.

Use the SQL JOIN Visualizer first. If you are not sure which JOIN type to use, design the query with SQL JOIN Visualizer before formatting it here.

CTEs improve readability. Complex queries with multiple subqueries are almost always clearer as CTEs (WITH clauses). The formatter shows the CTE structure clearly.

Diff before and after changes. After modifying a complex query, use Diff Checker to see exactly what changed — formatted queries produce much more readable diffs than minified ones.

🔗 Use These Together

🏁 Bottom Line

SQL queries are team-maintained code, and readable queries are easier to review, debug, and maintain. This formatter handles complex SQL including CTEs, window functions, and nested subqueries. For query design: SQL JOIN Visualizer.

Why would I format a SQL query — does it change the behavior?

Formatting only changes whitespace — it does not affect query execution. A SQL parser treats SELECT id FROM users WHERE active=1 and the same query spread across 6 indented lines identically. The reasons to format: ORM-generated queries (Hibernate, Sequelize, ActiveRecord) produce single-line output that is nearly impossible to read and debug. Query logs from production databases are often single-line. Code reviews are much easier with consistent indentation. Debugging complex joins is dramatically faster when the structure is visually clear.

Does this formatter support CTEs, window functions, and subqueries?

Yes. The formatter handles modern SQL: Common Table Expressions (WITH ... AS), window functions (OVER (PARTITION BY ... ORDER BY ...)), subqueries in SELECT and FROM clauses, CASE WHEN expressions, multiple JOINs with ON conditions, and UNION/INTERSECT/EXCEPT. Subqueries and CTEs are indented relative to their containing clause. If a complex query produces unexpected formatting, try pasting just the problematic subquery to isolate the issue.

Is it safe to paste production SQL queries here?

Yes — this tool runs entirely in your browser. The SQL you paste is processed by JavaScript on your device; nothing is sent to any server. This matters because production queries often contain table names, column names, and sometimes literal data values that reveal your schema. Server-based formatters log these requests. Using a browser-based formatter is the correct choice for any query touching real data or exposing your database structure.

What is the difference between uppercase and lowercase keyword formatting?

SQL keywords (SELECT, FROM, WHERE, JOIN) are case-insensitive — select and SELECT execute identically. Uppercasing SQL keywords exists to visually distinguish reserved words from identifiers (table names, column names). Most style guides and code formatters default to uppercase keywords. Some teams prefer lowercase for cleaner visual appearance. This tool defaults to uppercase but lets you choose — pick whichever matches your team's existing conventions.

How should I format a SQL query longer than my screen width?

The convention: start each major clause (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT) on a new line at the same indentation level, with continuation items indented one level further. SELECT columns should each be on their own line for queries with more than 2-3 columns. JOIN conditions go on the line after the JOIN keyword, indented. WHERE clause AND/OR conditions start each on a new line. This formatter applies these conventions automatically.

Can I format a SQL query that has syntax errors?

It depends on the error. Minor issues like non-standard functions may format fine since the formatter works mostly on token boundaries. Serious errors — missing parentheses, unmatched quotes, invalid keywords — will likely cause garbled or no output. Fix obvious syntax errors first, then format. The formatter often reveals structural issues that were invisible in the single-line original. If a query formats correctly but fails in the database, use EXPLAIN or the database error output to debug the semantic issue.

What other database and data tools are on this site?

The JSON Formatter is the natural companion for API development — format both the SQL query and the JSON response. The CSV to JSON tool converts database exports (typically CSV) to JSON for API use. The JSON to CSV tool converts API responses back to spreadsheet format. The Diff Checker compares two versions of a migration script before running it. The SQL JOIN Visualizer explains JOIN types with diagrams. All are in the Dev Tools section.