About SQLFormat

What this is

SQLFormat takes a wall of SQL — usually one line, usually copied out of a log, an ORM's debug output, or a colleague's -- TODO clean up this query — and lays it out so a human can read it. Keywords go on their own line, clauses indent by nesting depth, subqueries and CTEs line up with the thing they belong to. There is an UPPERCASE toggle, an indent-width choice, a dialect box, and a minifier for when the query has to fit somewhere. The dialect box is not four parsers: the layout pass is identical in every mode. It decides only the two spellings that mean opposite things in two engines — a bare # (a MySQL line comment or PostgreSQL's integer XOR) and a backslash inside single quotes (a MySQL escape, or a literal character in PostgreSQL and SQLite). Everything else, including JSONB operators, :: casts, backticks, DISTINCT ON and ILIKE, goes through exactly the same pass whatever you pick.

It runs entirely in your browser. Nothing is uploaded, nothing is stored, nothing is logged, because there is no server endpoint for the SQL to travel to. That matters more for this tool than for most: the queries people paste here are usually the ones attached to a production incident, full of table names, customer identifiers, and half-finished WHERE clauses about a specific account. A formatter with a backend would be reading your schema for a living. This one can't.

The one design decision you should know about

There is no SQL parser here. The formatter is keyword-anchored: it finds SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, and line-breaks around them at the right indent level. That is a deliberate trade and it has real consequences:

• It cannot validate anything. Broken SQL will be prettified into something that looks correct, which is worse than ugly broken SQL. Read what the formatter actually does before trusting it on anything machine-generated.
• String literals are not protected. A literal containing the word from can get split across lines.
• Dialect extensions — RETURNING, LATERAL, QUALIFY, BigQuery's SELECT * EXCEPT (...) — pass through untouched rather than being formatted or rejected.

The honest tradeoff: a real parser gives you safety and loses you speed and tolerance for garbage input. A keyword-anchored formatter is the opposite. For "make this query readable in the next four seconds" the second one wins, and that is the job this page has. For anything in a pipeline, use a real formatter — the alternatives page compares sqlglot, sqlfmt, and pg-formatter on exactly that axis.

Who runs it

One person, in the United States. sqlformat.net is one of a small family of single-purpose developer utilities — alongside curlparse.net, jsonbeautify.net, and regexcalc.net — where each site does one job in the browser and nothing else. There is no company behind it, no sales team, and nobody who will email you about a webinar. The person who reads your bug report is the person who fixes the formatter.

The guides are written from actual use, not scraped. When a page says "check your window functions after formatting," that is because the formatter got one wrong on a real query and I found out the unpleasant way. Where a claim is about the wider tooling market rather than this page, it links to the source — usually the npm downloads API or the upstream repository — so you can check it instead of taking my word.

Why it's free

A small, non-blocking ad slot pays for the domain and hosting, and that is the entire business model. Client-side tools are cheap to run: there is no backend to scale, no database to migrate at two in the morning, no usage spike to pay for. The formatter will stay free, will stay in the browser, and the privacy policy stays specific about what little is collected.

I also keep a public changelog, because "actively maintained" should be something you can verify rather than something a page claims.

Bugs, dialects it mangles, or a formatting rule you think is wrong: contact — a human reads every message, and defect reports get the most replies.