🔧 SQL Formatter Online

✨ Key Features

• Token-based beautifier — one clause per line (SELECT, FROM, WHERE, GROUP BY, ORDER BY, LIMIT …)
• Subqueries indented, and the opening parenthesis mirrored by a closing one on its own line
• CASE … WHEN … THEN … ELSE … END laid out as a block instead of one line
• AND / OR on their own line — while the AND that belongs to BETWEEN x AND y correctly stays inline
• Understands the quoting and comment styles in the wild: '…' with doubled or backslash escapes, "…", `…`, […], -- …, # …, /* … */ and PostgreSQL dollar-quoted bodies
• Minifier — collapse a query onto one line without touching literals or swallowing a line comment
• Structure check with line numbers: unbalanced parentheses, unterminated strings and comments, trailing commas before a clause or )
• Keyword casing (UPPERCASE / lowercase / leave as typed) and indent width (2, 4 or tab) as options
• Last five formatted queries kept in this browser only
• 100% client-side — your SQL never leaves your browser

💡 How It Works

Paste your query and press Format. The formatter lexes the text into tokens — keywords, identifiers, literals, comments, operators — then lays the token stream out again with one clause per line and one indent level per nesting depth. It is a pure whitespace transformation: the tokens come out in the same order, so the query means exactly the same thing to your database. No data is sent to any server; your SQL stays on your device.

This tool is part of the DevToolBox collection. Browse more tools in the Database & SQL category.

📖 What SQL Formatting Actually Does

Formatting is a purely structural transformation. The tokens stay in the same order and the query means exactly the same thing to the database; only the whitespace and line breaks change. That is why a formatter is always safe to run — it cannot alter semantics, only readability.

A good formatter does more than wrap lines, though. It should:

• Put every major clause — SELECT, FROM, WHERE, GROUP BY, ORDER BY — at a predictable indent level, so the eye can find them.
• Indent subqueries and parenthesised expressions explicitly, which makes nested logic visible instead of a wall of text.
• Align JOIN conditions with the table they belong to, so you can see which ON clause pairs with which JOIN.
• Leave string literals and comments alone. A formatter that reflows the inside of a quoted string is a broken formatter.
• Preserve the dialect's own quoting rules — backticks in MySQL, double quotes and :: casts in PostgreSQL, brackets in T-SQL.

The payoff is not aesthetic. Unformatted queries hide bugs: an AND that binds in the wrong place, a LEFT JOIN that is really an inner join because the filter moved into the WHERE clause, a correlated subquery buried in a single line. One line per clause and one indent level per nesting depth makes those mistakes visible at a glance.

🧾 What this formatter understands

SQL formatting goes wrong in one of two ways: the formatter rewrites something it should have copied (a string, a comment, a quoted identifier), or it gets confused by a delimiter it did not expect and runs the rest of the query together. This tool lexes the query first and classifies each token, which is why vendor syntax is handled without a dialect switch.

• String literals — 'text' with doubled quotes ('it''s') and MySQL-style backslash escapes ('it\'s'). Contents are never reflowed, so a comma or a parenthesis inside a string cannot break the layout.
• Quoted identifiers — PostgreSQL-style "column", MySQL-style `column` and T-SQL [column]. Keywords that appear inside them stay exactly as written.
• Dollar-quoted bodies — PostgreSQL $$ … $$ and $tag$ … $tag$, the construct that normally breaks naive formatters because it may contain semicolons.
• Comments — -- line, MySQL # line and /* block */. They keep their position, and minifying never swallows the rest of a statement after a line comment.
• Identifiers that look like keywords — a table called order or a column called date is only re-cased when it is used in a keyword position, matching how every other formatter behaves.
• Operators and casts — ::, ||, !=, <>, <=, >=, ->> and friends are kept as single units instead of being split into stray punctuation.

What it does not do: rename anything, rewrite LIMIT into TOP, prettify stored-procedure control flow, or parse your schema. Reformatting a 2,000-line migration will wrap clauses and indent subqueries; it will not restructure the logic.

🧪 Where a Formatter Fits in Your Workflow

• Reviewing a pull request. Format a changed query before reading the diff. Structural mismatches that were invisible in the one-line original become obvious.
• Reading an inherited query. Legacy reports are frequently a single 400-character line. Beautifying is the fastest way to work out what it selects.
• Reviewing a migration before it runs. Format the migration, then compare it against the previous version with a Diff Checker to see exactly which statement changed.
• Embedding SQL in application code. Minify it first, so the statement can sit in a single-line string without awkward line continuation.
• Sharing a query in a ticket or chat message. A formatted query is unambiguous; a single line is not.
• Teaching or documenting. Indentation is the cheapest way to explain a join graph or a window function.

A formatter is not a linter and not an optimiser. It will not tell you that a query is slow, that an index is missing, or that a SELECT * will break when a column is added. It makes the query readable so that you — or the next reviewer — can see those problems.

🧰 Related DevToolBox Tools

• JSON Formatter — beautify and validate the JSON columns and API payloads your queries return.
• Diff Checker — compare two queries or two migration files line by line.
• Timestamp Converter — turn the Unix timestamps stored in your tables into readable dates.
• Base64 Encoder/Decoder — decode Base64 values held in database columns.
• Hash Generator — checksums for fixtures and data-verification queries.
• Database & SQL category — GUI clients, hosted Postgres and MySQL, and schema designers.

❓ Frequently Asked Questions

Is SQL Formatter Online free to use?

Yes — completely free, with no sign-up and no usage limits.

Does it require an internet connection?

The tool runs 100% client-side in your browser. Once the page has loaded, no data is sent to any server.

Is it safe to paste a production SQL query?

Yes with DevToolBox. The formatter is client-side JavaScript: the query is parsed in your browser and never uploaded, which you can confirm in your browser's network tab. Remove literal credentials and customer data anyway — that is ordinary hygiene regardless of the tool.

Which SQL dialects are supported?

The formatter is token based rather than dialect bound, so it understands standard SQL and the vendor conventions that decide how tokens are delimited: MySQL backtick identifiers, T-SQL [bracketed] identifiers, PostgreSQL double-quoted identifiers and :: casts, and dollar-quoted function bodies. Statements such as LIMIT versus TOP are left exactly as you typed them — the tool never rewrites your SQL to another dialect.

Does formatting ever change what the query does?

No. Only whitespace moves. Strings, quoted identifiers and comments are lexed first and copied back byte for byte, so the token stream is identical before and after — that guarantee is covered by the project's test suite, which compares the token stream of every formatted and minified query against the input.

Can I minify SQL as well as beautify it?

Yes. The same tool both beautifies and minifies. Minifying collapses whitespace and line breaks so the query fits on one line, which helps when embedding a statement in application code or a config value where multi-line strings are awkward.

Do I still need a linter if I use a formatter?

Yes. A formatter changes how a query looks; a linter flags what it does — missing indexes, implicit casts, SELECT * in production code. Use the formatter to read the query and the linter to judge it.