SQL Formatter

Four ways a find-and-replace formatter breaks a query

Most browser SQL formatters are a stack of regular expressions. They uppercase every word on a keyword list, drop a newline in front of FROM and WHERE, then squeeze runs of whitespace down to a single space. The query is read as one flat string, and a flat string has no idea where a literal begins.

• Casing that reaches inside quotes. A support query filtering on WHERE subject = 'order by priority' comes back with the literal rewritten to 'ORDER BY PRIORITY'. Run that against your database and the row count changes. Load the Literal traps sample above to watch the same query survive here.
• Comments that swallow the code after them. Collapse whitespace first and every -- note absorbs whatever followed it, because the line break that ended the comment is gone. Output that looks tidy on screen deletes half the WHERE clause when it runs.
• Quoted identifiers read as ordinary words. MySQL quotes with backticks, SQL Server with square brackets, Postgres and SQLite with double quotes. A column named `group by` is legal in MySQL. A formatter blind to quoting splits it across two lines and recases both halves.
• Escaped quotes that end a string early.'O''Brien' is one literal holding an apostrophe, and MySQL also accepts 'O\'Brien'. A scanner that stops at the first apostrophe reads the rest of the statement as string content, so the indentation past that point is fiction.

The same query in two shapes

Here is a monthly revenue query as it usually arrives, copied out of application logs with the line breaks stripped, next to the default output on this page.

select o.id,c.name,sum(l.qty*l.unit_price) as total from orders o join customers c on c.id=o.customer_id where o.status='paid' and o.placed_at>='2026-01-01' group by o.id,c.name having sum(l.qty*l.unit_price)>250;

SELECT
o.id,c.name,SUM(l.qty * l.unit_price) AS total
FROM orders o
JOIN customers c
ON c.id = o.customer_id
WHERE o.status = 'paid'
AND o.placed_at >= '2026-01-01'
GROUP BY
o.id,c.name
HAVING SUM(l.qty * l.unit_price) > 250;

Notice what stayed on one line. The join condition, the aggregate and the HAVING test never needed their own rows, so they did not get them. Line breaks land where a list crosses a clause boundary, which is where a reader looks for them.

What each control moves

If your team has no house style yet, four spaces with trailing commas is the one to commit. It matches what most review tools and published SQL style guides already assume, and it survives being pasted into a ticket. Leading commas earn their keep once select lists run past twenty columns.

What happens between the paste and the output

Two passes, both in your browser.

The first pass reads the input one character at a time and sorts it into tokens: line comments, block comments, string literals, quoted identifiers, numbers, bind parameters, words and operators. Quoting rules follow the dialect chosen in the toolbar, so a backtick opens an identifier under MySQL and a dollar quoted block stays intact under Postgres. Once a run of characters lands inside a comment or a literal, nothing looks at it again.

The second pass arranges those tokens. Clause keywords such as SELECT, FROM, WHERE and GROUP BY start a line at the current block indent. A JOIN starts a line and its ON condition drops one level in, alongside the AND and OR conditions it reads with. A comma list breaks across rows only when the list runs to the end of its clause, which is why COUNT(*) and IN ('web', 'app') keep their commas inline while a five column select list stacks. Subqueries indent from the line that opened them instead of from the left margin, so AND user_id IN (SELECT ...) stays readable three predicates deep.

Casing happens at token level. A word is recased only when it matches the reserved word, data type or built-in function list. Table aliases, column names and every character between quotes are copied through unchanged.

Nothing is uploaded. No request carries the query text, no copy is stored, and the page keeps working with the network switched off after the first load. The counters below the panes read the finished output, where the statement figure counts top level semicolons and the longest line figure tells you whether the result fits your editor without wrapping. For the reverse trip, the SQL minifier takes the layout back out again.

Where this formatter stops short

It arranges text. It does not understand your schema, and it will happily return a broken query in beautiful shape.

• No syntax checking. Two problems raise a warning under the panes, an unbalanced bracket count and a string or comment that never closes, because both distort the layout. Everything else passes straight through. Send the result to a SQL query tester or a development database before it touches production.
• Procedural code lands flat. Stored procedure bodies, BEGIN and END blocks and T-SQL control flow are treated as ordinary statements. Nested block depth is not tracked, so those bodies come back with clause level indentation only.
• Dollar quoted bodies stay as typed. A Postgres $$ ... $$ block is held as one literal. That protects the body from being mangled and also means the SQL inside it goes unformatted. Format the body on its own if it needs the work.
• Reserved words used as identifiers get recased. An unquoted column named key becomes KEY under the uppercase setting. Quote it and the formatter leaves it alone, which is the same reason your database wants it quoted.
• No wrapping at a column limit. An IN list holding forty values stays on one line. The longest line counter is there so you spot it before a reviewer does.
• Large scripts re-read on every keystroke. Typing re-tokenizes the whole input after a short pause. A multi-megabyte dump will feel sluggish, and formatting a schema dump you only plan to skim is wasted work anyway. Paste the section you care about.