🗃️ SQL Formatter & Beautifier

Format and beautify SQL queries online. Supports MySQL, PostgreSQL, SQL Server, SQLite. Keyword casing, indent size, and minify mode.

SQL Input

Formatted Output

How to Use

Paste your SQL

Paste or type your SQL query into the left panel. Single queries, multi-statement scripts, and subqueries are all supported.

Choose options

Select the SQL dialect (MySQL, PostgreSQL, SQL Server, or SQLite), indent size, and keyword casing (UPPER or lower).

Format and copy

Click Format (or Ctrl+Enter) to beautify the query. Use Minify to compress it. Click Copy to use the result in your project.

Frequently Asked Questions

Does this SQL formatter support stored procedures? +

The formatter handles standard SQL including SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, and JOIN queries. Complex stored procedure syntax with BEGIN/END blocks, IF/ELSE, and DECLARE statements is formatted as best-effort.

What is the difference between beautify and minify? +

Beautify adds line breaks, consistent indentation, and keyword casing for human readability. Minify removes all extra whitespace to produce the smallest possible query string — useful for embedding in code or measuring query length.

Should SQL keywords be uppercase or lowercase? +

Both styles are equally valid — SQL is case-insensitive. The convention of UPPERCASE keywords (SELECT, FROM, WHERE) is traditional and widespread because it visually separates reserved words from table/column names. Many style guides (like Google SQL Style Guide) prefer lowercase for everything.

Does formatting change how the query runs? +

No. Formatting only affects whitespace and keyword case — it has no effect on query execution, performance, or results. The SQL engine ignores whitespace.

Is my SQL query sent to a server? +

No. All formatting runs entirely in your browser using JavaScript. Your SQL code never leaves your device.

Complete Guide: SQL Formatter & Beautifier

SQL queries are written once but read many times — by colleagues, in code reviews, in documentation, and by your future self during a 3am incident. Consistently formatted SQL is not a style preference, it's a legibility requirement. A SQL formatter automatically applies indentation, keyword casing, and clause breaks, transforming a dense one-liner into a readable, maintainable query.

Why Format SQL?

Consider this query:

select u.id,u.name,count(o.id) as order_count from users u left join orders o on u.id=o.user_id where u.created_at>'2024-01-01' group by u.id order by order_count desc limit 20

After formatting:

SELECT
    u.id,
    u.name,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o
    ON u.id = o.user_id
WHERE u.created_at > '2024-01-01'
GROUP BY u.id
ORDER BY order_count DESC
LIMIT 20

The structure becomes immediately obvious: which columns are selected, which tables are joined, and which conditions filter the result. Bugs like a missing JOIN condition or a wrong GROUP BY column are caught on visual inspection rather than after incorrect results appear.

Dialect Differences

While core SQL (SELECT/FROM/WHERE/JOIN) is standard, each database has extensions that affect formatting:

MySQL — backtick identifiers (`table_name`), LIMIT x, y syntax for pagination, GROUP_CONCAT.
PostgreSQL — double-quoted identifiers ("TableName"), dollar-quoted strings ($$...$$), window functions heavily used, RETURNING clause.
SQL Server (T-SQL) — square bracket identifiers ([column name]), TOP n instead of LIMIT, NOLOCK hints.
SQLite — permissive type affinity, no stored procedures, limited ALTER TABLE support.

Keyword Casing Conventions

SQL is case-insensitive for keywords, but style guides differ:

UPPERCASE (traditional) — SELECT, FROM, WHERE. Most widely used; clearly separates reserved words from identifiers.
lowercase (modern) — favored by Google SQL Style Guide and some teams that find uppercase harder to read at scale.
Mixed — avoid. Inconsistent casing is the worst of both worlds.

Pick one and enforce it with a formatter in CI. The SQL formatter here gives you both options.

Minifying SQL

When should you minify SQL? Almost never for queries that humans will read. However, minification is useful when:

Embedding SQL in JSON config files where whitespace increases payload size.
Logging queries compactly without losing information.
Building SQL dynamically in string concatenation where whitespace causes subtle bugs.

Performance and Formatting

Formatting affects zero query performance. The SQL engine tokenizes and parses the query before planning execution — whitespace and keyword case are discarded at the parser stage. The execution plan depends on indexes, statistics, and query structure, not on how the query is indented.

Common Mistakes

SELECT * in production — formatting reveals how many columns you're actually fetching. Explicit column lists are almost always better for performance and maintenance.
Implicit JOIN syntax — FROM a, b WHERE a.id = b.a_id is equivalent to INNER JOIN but hides the intent. Explicit JOIN syntax is clearer after formatting.
Missing parentheses around OR — WHERE a = 1 OR b = 2 AND c = 3 is parsed as a = 1 OR (b = 2 AND c = 3). Formatting with consistent indentation makes operator precedence visible.

For validating query results as JSON, use JSON Formatter. For generating test data to run against your schema, see Mock JSON Generator.