SQL Query Formatter

Formats to 16 dialects entirely in your browser — then proves nothing but whitespace changed, and tells you what is wrong with the query it just tidied up.

Free · No signup · Nothing leaves your browser

Formats to 16 dialects as you type, entirely in your browser. Then it does the part other formatters skip: it proves nothing but whitespace changed, and tells you what is wrong with the query it just tidied up.

Verified — only whitespace changed

All 48 tokens in your query survived formatting identically. Every string literal is byte-for-byte the same, every identifier, every number, every operator, in the same order — checked here in your browser, not assumed. Only whitespace and keyword casing differ.

What is wrong with this query

  • Warning
    SELECT * across a join

    Every column of every joined table comes back, including duplicated join keys, and the result set changes shape whenever someone adds a column. Name the columns you need.

  • Warning
    LIKE pattern starting with %

    A leading wildcard cannot use a normal B-tree index, so this scans the table however well indexed the column is. For substring search at any size, a full-text or trigram index is the fix.

  • Warning
    NOT IN over a subquery

    If the subquery returns even one NULL, NOT IN returns no rows at all — not an error, just an empty result that looks like a legitimate answer. NOT EXISTS behaves the way you expect and is usually faster too.

These are lexical checks on the query text. They know nothing about your indexes, your row counts or your data, so treat them as things worth a second look rather than verdicts.

StatementSELECTread only
Tables3users, orders, banned_users
Joins10 CTEs
Subqueries11 statement

Everything on this page runs in your browser. The query is never sent anywhere, never logged and never stored — which matters, because the queries worth formatting are usually the ones from production.

Tekk is a spec-driven development platform for people building software with AI coding agents — the same idea as this page, applied to a whole change rather than one query.

What formatting can and cannot promise

A formatter rearranges whitespace. That is the whole job, and every tool in this category makes the same implicit promise: your query still means what it meant.

None of them show their working. You paste a query, you get one back, and you decide whether to trust it — usually by skimming, which is exactly the thing you were trying to avoid by using a formatter.

This page checks instead. Both versions are broken into significant tokens — everything that carries meaning, with whitespace and comments discarded — and compared position by position:

Token type How it is compared
String literals Byte for byte. 'Active' and 'active' are different values.
Identifiers, keywords Case-insensitively — keyword casing is a formatting option.
Numbers, operators, punctuation Exactly, and in order.
Dollar-quoted bodies As one opaque token. The contents are usually not SQL.

If every token matches, the output differs from your input in whitespace and keyword casing and nothing else. That is a narrow guarantee, and stating it narrowly is the point: it says the query did not change, not that the query is correct.

The checks, and why these ones

The findings panel is deliberately short. A tool that flags everything trains you to ignore it, so each check earns its place by being wrong or expensive often enough to be worth interrupting for.

Danger — stop and look

  • UPDATE or DELETE with no WHERE. Applies to every row. If that is deliberate, TRUNCATE is faster for a delete and says so out loud.
  • Unconditional cross join. Comma-separated tables in the FROM with nothing joining them. Two tables of 10,000 rows return 100 million.

Warning — probably not what you meant

  • Comma joins with a WHERE. Legal, but the join conditions and the filters are mixed together, and deleting one line of the WHERE silently turns it into a cross product.
  • SELECT * across a join. Every column of every table, duplicated join keys included, and the shape changes whenever someone adds a column.
  • LIKE '%...'. A leading wildcard cannot use a B-tree index, so it scans the table however well indexed the column is.
  • NOT IN (subquery). If the subquery returns a single NULL, the whole thing returns no rows — not an error, just an empty result that looks like an answer. NOT EXISTS behaves as expected.

Note — worth knowing

  • A function around a filtered column. WHERE lower(email) = ... stops a plain index on email being used. An expression index restores it.
  • DISTINCT over a join. Often covering for a join that multiplies rows rather than a real need for unique values.
  • Large OFFSET. The database still walks and discards every skipped row, so page 500 costs far more than page 1.

These are lexical checks. They cannot see your schema, your indexes or your row counts, so they describe patterns rather than predict performance.

Why it runs in your browser

The queries worth formatting are the ones pulled out of a slow-query log or an ORM's debug output. They carry table names, column names and often literal values from production data.

Sending that to a server to have its whitespace rearranged is a poor trade. The engine — about 76 KB — is downloaded to your machine on your first keystroke and everything happens locally after that. There is no request to inspect, no log to leak and no account attached to it.

The query shown formatted before you type is computed at build time, so the page is complete on arrival rather than blank while something loads.

How it works

  1. 1

    Paste the query and pick your dialect

    Sixteen of them, from PostgreSQL and MySQL to Snowflake, BigQuery, DuckDB and Oracle. It formats as you type, with no submit button and no network request. If your query uses syntax from a different dialect — backticks under Postgres, SELECT TOP outside SQL Server — this sql query formatter says so and offers to switch.

  2. 2

    Check the verification line

    Every formatter implicitly promises it only changed whitespace. This one checks. Your query and the formatted output are both broken into significant tokens and compared one by one, so the page can tell you that all 48 tokens in the example above survived identically rather than asking you to trust it.

  3. 3

    Read what it found

    A DELETE with no WHERE, a comma join that is really a cross product, a LIKE starting with a wildcard, a NOT IN over a subquery that returns nothing the moment one row is NULL. A sql query formatter that only reindents leaves you to spot those yourself.

Frequently asked questions

Do you store or send my query anywhere?
No. The formatting engine is downloaded to your browser the first time you edit the query, and everything after that — formatting, the token comparison, the findings — happens on your machine. Nothing is uploaded, logged or stored, and there is no account. Worth knowing, because the queries actually worth formatting tend to be the ones from production.
Does formatting ever change what my query does?
It should not, and this page verifies rather than assumes. Both versions are split into significant tokens — string literals kept byte for byte, identifiers and keywords compared case-insensitively because casing is a formatting option — and checked position by position. If a single token differs you get a red panel naming it instead of a green one.
Which dialects does it support?
Standard SQL, PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), SQLite, BigQuery, Snowflake, Redshift, Spark, Trino, DuckDB, ClickHouse, Oracle PL/SQL, Hive and Db2. Picking the wrong one is the usual reason output looks odd, so dialect-specific syntax is detected and flagged.
Why does it flag problems instead of just formatting?
Because you are already looking at the query. A DELETE missing its WHERE is a thirty-second fix while it is on screen and a very long afternoon once it has run. A sql query formatter is the last thing to touch a query before it runs, which makes it the right place to say something. The checks are conservative on purpose — they fire on patterns that are wrong or expensive often enough to be worth interrupting for, not on every stylistic preference.
What does it actually check for?
UPDATE or DELETE with no WHERE, comma joins and unconditional cross products, SELECT * across a join, LIKE patterns starting with a wildcard, NOT IN over a subquery, functions wrapped around filtered columns, DISTINCT masking a join fan-out, and pagination by large OFFSET. Each one explains the fix, not just the smell.
Are the warnings reliable?
They are lexical checks on the query text, so they know nothing about your indexes, row counts or data distribution. Treat them as things worth a second look rather than verdicts. They will not tell you a query is slow — they will tell you it contains a pattern that is often slow, which is a different and more honest claim.
Does this sql beautifier keep my comments?
Yes, both line comments and block comments, in place. This is checked by a test on every build rather than left to chance, because a sql beautifier that silently ate the comment explaining why a join exists would be actively harmful.
Can it handle CTEs, window functions and subqueries?
Yes. Nested CTEs, window functions with their own PARTITION BY and ORDER BY, long IN lists, CASE expressions, UNION and dollar-quoted function bodies are all handled, and each has a test asserting the tokens survive. Those are the cases where a half-written parser quietly mangles something.
Why does the page pause the first time I type?
It is fetching the formatting engine — about 76 KB — which is not sent to people who only wanted to read the page. The formatted query shown before you type is computed at build time, so the page is never blank while it waits.
Is there a limit, or a paid tier?
No. There is nothing to meter, because nothing runs on our servers — this sql formatter online costs us nothing per use, so there is no run limit, no signup wall and no upsell inside the tool.
How is this different from any other sql formatter online?
Most format and stop. The two things this sql query formatter adds are the token-level proof that meaning was preserved, and the findings panel. If you only need reindenting, any sql formatter online will do the job; the difference shows up when the query has something wrong with it.
Can I use the output in a migration?
The verification covers exactly one thing: the formatted output contains the same tokens as your input, in the same order. That is a real guarantee and a narrow one. It says the query did not change — it says nothing about whether the query was right to begin with.
Why is this free, and what is Tekk?
Tekk is a spec-driven development platform for people building software with AI coding agents. Checking that a change did what it claimed, rather than trusting it, is the same idea as this sql beautifier applied to a whole codebase. This page costs nothing to run and there is no upsell in it.

Want a real spec for what you’re building?

Drop a sentence. Tekk grounds it in your actual code and turns it into an executable plan.

Free to try · Connect GitHub during signup