Skip to main content
QUIETLYTIC
Developer

SQL Formatter

Reflow a SQL query onto readable lines, one clause per line.

Local · nothing leaves this browser Waiting for a query
Esc Clear
Formatted

Paste a query on the left.

How it works

Recognises common clause keywords — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, and their kin — uppercases them, and breaks the query onto one line per clause with comma-separated lists indented underneath.

A reflow, not a validator

This is a tokenizer, not a parser for any specific SQL dialect. It does not check that the query is syntactically correct for any engine. Anything whose content matters — string literals, "double-quoted", T-SQL [bracketed] and MySQL backtick identifiers, PostgreSQL $$…$$ bodies, and comments — is copied through byte-for-byte, never re-spaced or re-cased.

Comments stay where they can't swallow code

A -- line comment runs to the end of its line, so the formatter always ends the output line after one. Pulling the next clause up onto that line would comment it out and silently change what the query does.

Example

A comma inside a function call, like COUNT(a, b), stays on the same line as the call — only top-level commas (a SELECT column list, an INSERT value list) break onto new lines, tracked by parenthesis depth.

Frequently asked questions

Does this check whether my SQL is valid?

No. It recognises common clause keywords well enough to reflow them onto their own lines, but a query with a genuine syntax error will still format without complaint — this is a layout tool, not a parser or linter.

Why does a comma inside a function call not break onto a new line?

The formatter tracks parenthesis depth and only breaks top-level commas — the ones separating a SELECT column list or an INSERT value list — onto new lines. A comma inside COUNT(a, b) stays on the same line as the function call.

Related tools

From the intelligence desk