Can it change what my query does?

No. Formatting alters whitespace and keyword casing only, and a test asserts that the token stream coming out matches the one going in for every sample query. String literals, comments and quoted identifiers are single tokens and are never modified.

Which dialect does it understand?

The tokeniser handles the syntax common to PostgreSQL, MySQL, SQL Server and SQLite, including all three quoted-identifier styles: "double", `backtick` and [bracket]. It is a formatter rather than a parser, so it does not validate dialect-specific grammar.

Is my query sent to a server?

No. It is formatted entirely in your browser. That matters more here than for most tools, because a query being debugged often has real table names and real values in it.

JSON & Data

SQL Formatter and Beautifier

Paste a query to lay it out with one clause per line and conditions indented under it. Only whitespace and keyword casing change — the query itself is untouched.

SQL1 line

Formatted7 lines

SELECT u.id,
  count(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.country IN ('IN', 'US')
GROUP BY u.id
HAVING count(o.id) > 5

Indent

This tool runs entirely in your browser. Your input is never uploaded, stored or logged.

How it works

The query is tokenised before anything is laid out, which is the whole point. A formatter built from regular expressions over raw text corrupts queries in ways that are invisible afterwards: it uppercases the word "order" inside a string literal, breaks a line in the middle of a comment, and mangles an identifier that happens to be spelled like a keyword. Here a string, a quoted identifier and a comment are each a single token, and their contents are never examined or altered.

Layout then works on the token stream. Top-level clauses start a line, join phrases stay together so LEFT OUTER JOIN is not spread across three lines, AND and OR are indented under the clause they belong to, and commas in a select list break while commas inside a function call do not. A parenthesis followed by SELECT opens a subquery and gets its own indented block; one following a name is a call or a column list and stays inline.

The property the tests assert is that formatting changes whitespace and keyword casing and nothing else — the sequence of tokens coming out is the sequence that went in, and formatting an already-formatted query changes nothing. A pretty-printer that quietly alters what a query means is worse than no pretty-printer, because the damage is not visible by looking at the result.

Common problems

Every example below is run against this tool in our test suite, so what it says here is what the tool actually does.

A string literal was opened and never closed.

select * from t where name = 'O'Brien'

Why:: A single quote inside a SQL string has to be doubled, not backslash-escaped. Written this way the literal ends at the quote in the middle of the name and the rest of the line becomes syntax.
Fix:: Double the quote: 'O''Brien'. Better still, bind it as a parameter and let the driver handle it.

A block comment was opened with /* and never closed.

select 1 /* todo

Why:: Block comments do not nest and are not ended by a newline, so an unclosed one swallows the remainder of the statement and anything appended to it later.
Fix:: Close it with */, or use -- for a comment that ends at the line break.

Keywords in my data got uppercased by another formatter.

Why:: Formatters that work on raw text cannot tell a keyword from the same word inside a string literal, so uppercasing rewrites the data in the query.
Fix:: Nothing to do here — string contents are never touched. Check any other formatter in your pipeline against a query containing a value like 'order by'.

Frequently asked questions

Can it change what my query does?: No. Formatting alters whitespace and keyword casing only, and a test asserts that the token stream coming out matches the one going in for every sample query. String literals, comments and quoted identifiers are single tokens and are never modified.
Which dialect does it understand?: The tokeniser handles the syntax common to PostgreSQL, MySQL, SQL Server and SQLite, including all three quoted-identifier styles: "double", `backtick` and [bracket]. It is a formatter rather than a parser, so it does not validate dialect-specific grammar.
Is my query sent to a server?: No. It is formatted entirely in your browser. That matters more here than for most tools, because a query being debugged often has real table names and real values in it.

Last updated 20 September 2026