SQL Formatter & Syntax Checker

How to use it

1. Paste your query. It stays in your browser — there’s no request to anywhere.
2. Pick your dialect. This changes how the query is read, not just how it’s printed.
3. Read the verdict, then copy the formatted SQL.

Tick “Minify instead” to go the other way and collapse everything onto one line.

Your query never leaves this page

This is the part worth being explicit about, because most online SQL formatters work the other way round.

A SQL query is not neutral text. It names your tables and your columns. It often contains real values — an email address in a WHERE clause, an internal ID, occasionally a literal password in a seed script. Paste that into a formatter that POSTs to a backend and you’ve disclosed a slice of your schema to a third party, along with whatever was in the literals.

Everything here runs in JavaScript in your browser. There is no upload, no API call, and no server-side component to have a retention policy. Disconnect from the internet after the page loads and it keeps working.

It never runs your SQL

There is no database on this page and no connection to one. The tool reads your query as text, works out where each token ends, and prints it back with different spacing.

That’s a real limitation, not just a safety claim. Because nothing executes, the tool cannot tell you whether a table exists, whether a column name is spelled right, or whether a join will return what you expect. It can only tell you about the text.

What the checker actually checks

Structural problems it can prove from the text alone:

A query that passes is not guaranteed to run. This is not a full SQL grammar, and it never will be — that would mean writing a parser for five dialects and having your schema to check against. It catches the four mistakes that account for most “why won’t this parse” moments, and it tells you exactly where they are.

The O’Brien example is the one that catches everyone. The apostrophe closes the string, and everything after it is read as SQL. The fix is to double it: 'O''Brien'.

Why the dialect setting matters

Most formatters have a dialect dropdown that changes nothing. Here it changes how your query is read, because dialects genuinely disagree about where a token ends.

Pick the wrong one and a valid query can look broken. Paste MySQL backticks with PostgreSQL selected and the backtick isn’t an identifier quote at all, so the tokeniser reads the rest of the line as something else entirely.

Dialect differences the formatter won’t fix

Formatting is cosmetic. These differences are semantic, and no formatter can translate between them:

If you’re porting a query between engines, these are the lines to look at first.

PostgreSQL syntax checker

Set the dialect to PostgreSQL and the checker reads your query the way Postgres does.

Identifiers are quoted with "double quotes". Leave one unclosed and the error names that character specifically — no closing “ — with the line and column, rather than a generic parse failure.

The one that catches people is dollar quoting. A function body written as $$ ... $$ can contain semicolons that are not statement separators. Paste SELECT $$a;b$$ with PostgreSQL selected and you get one statement, which is correct. Select MySQL instead and the same text reads as two, because MySQL has no dollar quoting and that semicolon becomes a boundary.

Paste MySQL backticks with PostgreSQL selected and you get a warning saying so, and naming " as the replacement — Postgres does not accept backticks as identifier quotes at all.

MySQL and MariaDB syntax checker

MySQL quotes identifiers with `backticks`, and the checker treats them as such. An unclosed one reports no closing `.

Two things differ from the ANSI dialects. # starts a comment to end of line, which nothing else here supports. And a backslash escapes inside string literals, so 'a'b' is one string rather than the start of a second one.

Square brackets get flagged. They are SQL Server and SQLite syntax; MySQL reads [ as an ordinary character, so a query pasted from SQL Server tokenises into something quite different from what you meant.

T-SQL and SQL Server syntax checker

SQL Server quotes identifiers with [square brackets]. Select this dialect and an unterminated one reports no closing ].

Brackets are the reason a T-SQL query pasted under the wrong dialect looks broken. Under MySQL you get a warning rather than silence, which is the point — the query is fine, the setting is wrong.

The differences the checker cannot fix are the semantic ones in the table above: TOP 10 where other engines write LIMIT 10, + for string concatenation where Postgres and Oracle use ||, and GETDATE() in place of NOW(). Formatting is cosmetic; those are rewrites.

Oracle syntax checker

Oracle uses "double quotes", and quoting an identifier makes it case-sensitive — "Users" and "users" are different tables, which is not true of the unquoted form.

Oracle is the strictest of the five here. It is the only dialect where both square brackets and backticks produce a warning, because it accepts neither. Queries arriving from SQL Server or MySQL usually trip at least one.

For row limiting, older Oracle code uses ROWNUM in a WHERE clause; 12c and later support FETCH FIRST n ROWS ONLY. Neither is LIMIT, and no formatter converts between them.

SQLite syntax checker

SQLite is deliberately the most permissive of the five. It accepts double quotes, square brackets and backticks as identifier quotes, so the checker accepts all three without complaint when this dialect is selected.

That leniency is worth knowing about rather than relying on. A query that passes here because SQLite tolerates its quoting style may not survive being moved to Postgres or Oracle. If the query is destined for another engine, check it under that engine’s dialect instead — the warnings you want are the ones SQLite declines to give you.

What formatting changes, and what it doesn’t

Only two things change: whitespace, and the capitalisation of keywords.

Everything else is copied through byte for byte — string contents, identifiers, numbers, comments. The test suite checks this directly: it tokenises the query before and after formatting and asserts that every token comes out in the same order. If formatting could alter what a query means, the tool would be worse than useless.

Formatting is also idempotent. Format twice and you get the same result as formatting once, which is what makes the output safe to commit.

Keyword casing

SQL keywords are case-insensitive, so this is purely about readability.

Uppercase keywords are the long-standing convention, and there’s a decent reason for it: it makes the skeleton of a query scannable. Your eye finds SELECT, FROM and WHERE without reading the identifiers between them. That’s the default here.

Plenty of modern codebases use lowercase throughout, on the grounds that shouting is unnecessary when syntax highlighting exists. Both are defensible. The third option leaves your capitalisation exactly as typed, which is what you want when a diff would otherwise be noise.

Worked example

Paste this in:

select o.id,c.name,count(i.id) as items from orders o join customers c on o.customer_id=c.id left join items i on i.order_id=o.id where o.status in ('paid','shipped') group by o.id,c.name having count(i.id)>1 order by items desc limit 50;

You get back:

SELECT o.id, c.name, COUNT(i.id) AS items
FROM orders o
JOIN customers c
  ON o.customer_id = c.id
LEFT JOIN items i
  ON i.order_id = o.id
WHERE o.status IN ('paid', 'shipped')
GROUP BY o.id, c.name
HAVING COUNT(i.id) > 1
ORDER BY items DESC
LIMIT 50;

Each clause gets its own line, joins get theirs, and the ON conditions indent underneath the join they belong to. The verdict underneath reads “no structural problems found in 1 statement”.

Note that 'paid' and 'shipped' come through untouched, and COUNT(i.id) keeps its bracket while orders o doesn’t gain one.

Why your SQL won’t parse

In rough order of how often each one actually happens.

1. An apostrophe inside a string. 'O'Brien', 'it's', 'don't'. The apostrophe closes the string early. Double it: 'O''Brien'. This is far and away number one, and it’s also the source of a whole category of SQL injection, which is why parameterised queries exist.
2. A bracket opened and never closed. Usually in a subquery or a long IN list. The checker names which one.
3. A trailing comma. SELECT a, b, FROM t — added while editing a column list and never removed.
4. A reserved word used as a column name. order, group, user, key, desc. Quote it with whatever your dialect uses and it’s fine.
5. A dialect mismatch. Backticks pasted into PostgreSQL, or brackets into MySQL. Change the dropdown before assuming the query is broken.
6. A block comment left open. Someone commented out a clause with /* and never added the */. Everything after it vanishes into the comment.

The first, third and fourth are worth internalising because no tool can fully protect you from them. A trailing comma is structurally fine — brackets balance, strings terminate — so it passes the checks here and fails at the database. That’s the honest boundary of text-level validation.

House style: comma-first and the river

Two conventions you’ll meet in real codebases, neither of which this tool produces.

Comma-first puts the comma at the start of the line rather than the end:

SELECT id
     , name
     , email
FROM users

The argument for it is real: adding or removing a column is a one-line diff, and a missing or trailing comma is visible at a glance because the commas line up. The argument against is that most people find it ugly. It’s common in data teams and rare elsewhere.

River formatting right-aligns keywords so a channel of whitespace runs down the middle:

  SELECT id, name
    FROM users
   WHERE active = 1
ORDER BY name

It reads beautifully at a glance and it’s miserable to maintain by hand, since adding a longer keyword re-aligns everything. Some formatters offer it as a mode.

This tool produces the conventional left-aligned, comma-last layout, which is what the overwhelming majority of SQL in the wild looks like. If your team has settled on something else, use your editor’s formatter with that config — consistency inside a codebase beats any individual convention.

Minifying

The reverse operation. It collapses the query to one line, drops comments, and removes every space that isn’t needed to keep tokens apart — including the space after commas, which SQL doesn’t require.

Useful when a query has to live somewhere that hates newlines: a config file, a URL parameter, a log line, a single-line CSV cell.

One thing minify never touches is whitespace inside a string literal. 'a b' keeps both spaces, because collapsing them would change the data rather than the formatting. If a minifier ever does that to you, stop using it.

Formatting SQL elsewhere

Use the editor integration for anything you do regularly. A web page is the right tool for a query someone pasted into a ticket, not for your daily workflow.

Related tools

Query results and API payloads usually arrive as JSON, and JSON compare shows what changed between two of them without being confused by key order. For configuration and older enterprise formats, XML compare does the same structurally. If a value is arriving mangled, the hex, binary and ASCII converter shows you the actual bytes, and the URL encoder explains what percent-encoding did to it in a connection string. Tokens in a database-backed auth flow can be read with the JWT decoder.