Skip to content
ToolBoxGeniehome

SQL Formatter

Developer Tools · Added

Paste a query that arrived as one long line and get it back readable — clauses on their own lines, join conditions indented under their joins, subqueries nested, and reserved words cased consistently. It runs on a tokeniser rather than a pattern match, so a keyword inside a string literal is left exactly as you wrote it. Nothing is uploaded and no query is executed.

Mode

Applies to reserved words only, never to your table or column names.

Formatted in your browser. Nothing you paste is uploaded, and no query is run.

How to use the sql formatter

  1. 1Paste your SQL, or press Load a sample query to see what the output looks like.
  2. 2Choose Beautify to lay it out, or Minify to squeeze it back onto one line.
  3. 3Set the indentation and whether reserved words should be uppercase, lowercase or left alone.
  4. 4Copy the result or download it as a .sql file.
  5. 5Check the bracket and string warnings underneath — they flag the two things that make a query unparseable.

Examples

A joined aggregate query

Input
select u.id, count(o.id) from users u left join orders o on o.user_id = u.id group by u.id
Result
SELECT u.id, count(o.id)\nFROM users u\nLEFT JOIN orders o\n ON o.user_id = u.id\nGROUP BY u.id

The join condition is indented under the join it belongs to, which is what makes a five-table query scannable.

A subquery

Input
select * from (select id from a union all select id from b) t
Result
SELECT *\nFROM\n (\n SELECT id\n FROM a\n UNION ALL\n SELECT id\n FROM b\n ) t

Brackets become nesting, so the inner query is formatted by the same rules one level deeper.

A keyword inside a string

Input
select 'order by' as label from t
Result
SELECT 'order by' AS label\nFROM t

The literal is untouched. A regex-based formatter would have uppercased it or broken the line inside the quotes.

About the sql formatter

Why formatting is the cheapest code review tool there is

A query that arrives as a single 400-character line is not reviewable. Nobody can see which conditions belong to the join and which to the filter, whether the aggregate is grouped by everything it should be, or that a table has been joined twice. Laying it out changes none of the meaning and most of the comprehension, which is why the first thing an experienced reviewer does with an unfamiliar query is reformat it.

The same applies to diffs. A stored query edited by two people in two brace styles produces a diff where every line changed and nothing can be reviewed. Running both versions through the same formatter first collapses that back to the lines that genuinely differ. It is the identical argument that applies to code formatters, and it applies more strongly to SQL because SQL is so often stored as a string in some other language.

Consistent keyword casing does a smaller version of the same job. Uppercase reserved words are a convention rather than a requirement — SQL is case-insensitive about them — but the convention makes the structure of a query visible at a glance, because the words that shape the query look different from the words that name your data. This tool restricts recasing to genuine reserved words for that reason, and leaves things like a column named status alone.

What a formatter cannot tell you

A beautifully formatted query can be completely wrong. Formatting says nothing about whether the join condition is right, whether a LEFT JOIN has been undone by a WHERE clause on the right-hand table, or whether the aggregate silently drops rows. Those need a database, an execution plan and test data, none of which live in a text formatter.

It also says nothing about performance. Indentation does not change the plan the optimiser picks; the same query formatted three ways executes identically. Where formatting helps indirectly is in making an expensive pattern visible — a correlated subquery buried in a select list is obvious once it is indented and invisible when it is inline.

The one thing the layout can genuinely reveal is a structural mistake, and bracket balance is the clearest case. A query with an unclosed bracket will format oddly and the counter under the output will say so, which is usually faster than reading the engine error message that names a position rather than a cause.

Frequently asked questions

Does this run my query or send it anywhere?
No to both. There is no database behind this page and no request leaves your browser — the query is parsed into tokens by JavaScript running in your tab and reassembled as text. That is deliberate, because queries routinely contain table names, filter values and occasionally credentials in a connection comment, and a formatter has no business seeing any of it on a server.
Which SQL dialect does it understand?
It is dialect-agnostic by design. It recognises the quoting rules all the major engines share — single quotes for strings, plus ANSI double quotes, MySQL backticks and SQL Server square brackets for identifiers — and formats around clause keywords that are common to all of them. It makes no attempt to parse dialect-specific syntax into a tree, so anything it does not recognise is passed through exactly as written rather than guessed at.
Why did a short clause stay on one line?
Because breaking it would make it harder to read, not easier. The formatter measures each clause in its inline form first and only expands it if it exceeds the line width or contains a subquery. So a WHERE with one condition keeps its line while a WHERE with four conditions splits at each AND. This is also why the output is stable: running it twice gives the same result as running it once.
Are line comments safe when minifying?
They are removed, always, and that is the safe behaviour rather than a limitation. A double-dash comment runs to the end of its line, so collapsing a query onto one line would put everything after the comment inside it and silently disable half the query. Block comments are kept unless you tick the option, since they cannot swallow what follows them.

Related tools