SQL Formatter

What is a SQL formatter?

A SQL formatter takes a SQL statement and rearranges the whitespace around it — line breaks, indentation, keyword casing — without touching anything that affects what the query returns. It does not validate the query, run it, or optimise it; it takes the tokens you already wrote and lays them out so a person can read them at a glance instead of tracing a single unbroken line.

Three situations call for one, over and over. A query pasted out of a slow-query log or an error message, dumped on one line with no spacing to speak of. A query an ORM generated for you, technically correct and practically unreadable, every join and condition run together. A query inherited in someone else's report or script, written to conventions that are not yours, that you need to read closely before you trust it enough to change.

This page does exactly that layout work, in the browser: paste SQL into the left pane and the formatted version appears on the right as you type, with a button to copy it back out. A dialect picker, an indent choice, and a keyword-case switch cover the decisions that actually vary from one house style — and one database — to the next.

How to format a SQL query

1. Paste your SQL. Drop the statement into the left pane; there is no file to upload and no size limit to declare.
2. Set the dialect and style. Choose Standard, MySQL, SQL Server, or PostgreSQL, then pick an indent width and a keyword case to match your convention.
3. Copy the result. The formatted query appears on the right as you type, alongside a count of the tokens copied through untouched, ready to copy with one click.

What formatting can actually promise

There is no SQL formatting specification. XML has one, and Markdown has CommonMark, backed by 652 worked examples of exactly how each construct renders. SQL has neither. Where a clause breaks, how deeply a subquery indents, whether keywords are shouted or left alone — all of that is house style, not a rule anyone wrote down. So “correct” is undefined for this job, and any tool that advertises a percentage of correctness has invented the yardstick it is measuring against.

What can be guaranteed, and is, is narrower and more useful: formatting never changes what the query does. Every string literal, quoted identifier, and comment comes out byte for byte as it went in. The sequence of tokens is unchanged — nothing added, nothing dropped, nothing reordered. Only the whitespace between tokens moves, and only keyword case changes.

That is not a promise made in the abstract; it is enforced by a test. The token stream is compared before and after formatting, across a hand-written corpus and a 1,500-statement generated sweep spanning all four dialects, plus a control case that proves the comparison is actually capable of failing rather than passing by default. 1,802 assertions run against that guarantee in total.

It matters because the failure mode is silent otherwise. A formatter that breaks a new line on every comma will break one inside a string literal too, turning a piece of your data into two lines. One that upper-cases every keyword will upper-case the word select sitting inside a string, or inside a column that happens to be named “select”. Neither of those is a cosmetic slip — both change the query's results, not just its appearance.

Why the dialect matters, and why the rules stay small

The dialect picker is not a styling preference — it is the one control on this page where guessing wrong corrupts a query, because it selects the quoting rules a dialect actually uses. Formatting has to know which characters are punctuation and which are data.

MySQL quotes identifiers with backticks and treats a hash sign as the start of a line comment. SQL Server quotes identifiers with square brackets, so a bracketed reserved word is a column name, not a keyword. PostgreSQL and standard SQL use double quotes, and PostgreSQL additionally allows dollar-quoted bodies — text between a matching pair of dollar signs — whose contents can include semicolons, quotes, or anything else at all.

Get the dialect wrong and the damage is concrete, not stylistic. Read a backtick-quoted MySQL query under standard rules and the backticks look like ordinary punctuation to be moved around. Read a PostgreSQL function body without dollar-quote support and its contents get mangled as though they were ordinary SQL to indent and re-case. There is no safe default that covers both cases, which is exactly why the tool asks instead of assuming.

The layout rules themselves are deliberately few: clause keywords start a line, joins indent one level under them, parentheses open a level, and commas break the line. Anything the formatter does not recognise is passed straight through rather than guessed at. That is a smaller rule set than some tools offer, and it follows the same principle as the correctness guarantee above — when in doubt, preserve what you do not understand rather than rewrite it.

Why is it free?

Formatting SQL is text rearrangement, and a browser can do that as fast as a server can — so there is no reason to make it one. Everything on this page runs on your machine: the SQL you paste is never uploaded anywhere, there is no account to create, and nothing is watermarked or rate-limited. Paste, format, copy, and the tab can be closed without a trace left on any server.