How to Format and Beautify SQL Online (Free Tool)

Someone pastes a 900-character query into the team chat with “why is this slow?” and it’s all on one line. Before anyone can answer, someone has to make it readable. That someone is usually you.

Why formatting SQL matters

SQL doesn’t care about whitespace. A query on one line runs exactly like the same query spread over fifty. That’s handy for a quick ad-hoc query, but it hurts once other people have to read the code.

Unformatted SQL causes three problems:

Logical errors are harder to spot. With the WHERE clause, a JOIN condition and an aggregate on one line, a missing condition or a wrong alias is easy to overlook.
Reviews take longer, because the reviewer has to work out the structure before checking the logic.
Diffs get noisy when people reformat queries in different ways from commit to commit.

A consistent style fixes all three. Queries can be scanned at a glance, and diffs only show real changes.

SQL style guides

The well-known style guides differ in detail but agree on the basics: case keywords consistently, put each major clause on its own line, and indent to show structure.

sqlstyle.guide by Simon Holywell right-aligns keywords so that column names line up in one column, with a “river” of whitespace between them. It reads well but looks unusual to many developers.
The GitLab SQL style guide is more conventional: uppercase keywords, each clause on a new line, and four-space indentation.

The particular style matters less than applying one everywhere. Pick a guide, set your formatter to match, and use it across the team.

Uppercase or lowercase keywords

Uppercase keywords separate SQL syntax from table and column names. In SELECT name FROM users WHERE active = true, the keywords stand out as signposts.

Lowercase keywords are quicker to type, and syntax highlighting already colors keywords in most editors, which weakens the case for capitals.

Uppercase is still the most common convention. Most style guides, formatters and database manuals use it, so it’s a safe default for a new project. If a codebase already uses lowercase consistently, there’s no reason to change it. The PulpMiner formatter always uppercases SQL keywords.

Indentation conventions

Two spaces is compact and suits short queries and narrow terminal clients.
Four spaces is the most common choice. It shows the structure clearly without pushing deep nesting off the screen.
Tabs let each developer choose the width. They are less common in SQL, but some teams use them in every language.

Beyond the indent unit, there are conventions for what gets indented. Columns after SELECT go one level in. JOIN often sits one level under FROM, with its ON condition one level further. Each AND or OR in a WHERE clause starts its own line.

Here’s a typical query as it often arrives, straight from a log:

Before

select u.id, u.name, u.email, o.order_date, o.total from users u inner join orders o on u.id = o.user_id where u.active = true and o.total > 100 order by o.order_date desc limit 50;

After

SELECT
    u.id,
    u.name,
    u.email,
    o.order_date,
    o.total
FROM
    users u
    INNER JOIN orders o
        ON u.id = o.user_id
WHERE
    u.active = true
    AND o.total > 100
ORDER BY
    o.order_date DESC
LIMIT
    50;

Same query, same result, very different experience. In the formatted version you can see at a glance which columns are selected, how the tables are joined, which filters apply, and how the result is ordered and limited.

Formatting subqueries

Nested subqueries are where formatting helps most. Indent each subquery one level deeper than the clause around it, and put the closing parenthesis on its own line, lined up with the line that opened it.

Before

select * from users where id in (select user_id from orders where total > (select avg(total) from orders where order_date > '2025-01-01'));

After

SELECT
    *
FROM
    users
WHERE
    id IN (
        SELECT
            user_id
        FROM
            orders
        WHERE
            total > (
                SELECT
                    AVG(total)
                FROM
                    orders
                WHERE
                    order_date > '2025-01-01'
            )
    );

Each level of nesting is visible, so you can follow the logic from the outer query inward instead of counting parentheses on your fingers.

Common table expressions

A CTE, written with WITH, is often easier to read than a subquery. Give each CTE its own block, indent its body, and keep the final SELECT separate.

SQL

WITH active_users AS (
    SELECT
        id,
        name,
        email
    FROM
        users
    WHERE
        active = true
),
recent_orders AS (
    SELECT
        user_id,
        SUM(total) AS total_spent
    FROM
        orders
    WHERE
        order_date > '2025-01-01'
    GROUP BY
        user_id
)
SELECT
    au.name,
    au.email,
    ro.total_spent
FROM
    active_users au
    INNER JOIN recent_orders ro
        ON au.id = ro.user_id
ORDER BY
    ro.total_spent DESC;

Formatted this way, the query reads as a series of named steps, and you can debug each step by running its SELECT on its own.

Formatting INSERT, UPDATE and DELETE

The same ideas apply outside SELECT. List the columns and values of an INSERT one per line, put each SET assignment of an UPDATE on its own line, and indent the WHERE clause of a DELETE the same way as in a query.

SQL

INSERT INTO users (
    name,
    email,
    role,
    created_at
)
VALUES (
    'Priya Raman',
    'priya@example.com',
    'admin',
    NOW()
);

SQL

UPDATE users
SET
    role = 'admin',
    updated_at = NOW()
WHERE
    email = 'priya@example.com'
    AND active = true;

Dialect differences

SQL is a family of dialects. PostgreSQL uses :: for type casts, MySQL quotes identifiers with backticks, SQL Server uses square brackets, and BigQuery has STRUCT and ARRAY types. A dedicated formatter such as sqlfluff lets you pick a dialect so it can parse these correctly.

How to use the SQL formatter

Open the SQL formatter and paste your query.
Choose Format or Minify. In format mode, pick an indent of 2 or 4 spaces.
Select Beautify (or Minify) and Copy the output.

Formatting uppercases keywords, starts each major clause such as SELECT, FROM, JOIN, WHERE and ORDER BY on a new line, and indents the contents of parentheses so subqueries and CTE bodies stand out. Minifying removes comments and collapses the query onto a single line.

Before either step, the tool checks for unbalanced parentheses, unclosed strings, unclosed quoted identifiers and unclosed /* */ comments, and tells you what is wrong. It doesn’t take a dialect setting, and everything runs in your browser.

Making formatting automatic

Editor extensions. VS Code, JetBrains IDEs and Vim all have SQL formatters. Turn on format on save.
Pre-commit hooks. Run sqlfluff or sqlfmt before each commit.
CI checks. Fail the build when a query doesn’t match the agreed format.
Online tools. For a one-off query copied from a log, a chat message or documentation, paste it into an online formatter.

Writing readable SQL

Use meaningful aliases. u for users and o for orders beats t1 and t2.
Qualify column names. In a query with more than one table, prefix every column with its alias so it’s clear where it comes from.
Comment the non-obvious. Use -- comments to explain business rules and performance tricks.
Split long queries. Break a very long query into CTEs or temporary tables.
Avoid SELECT *. Listing columns documents what the query needs and protects it from schema changes.

How to format and beautify SQL online