Keyword matching is regex-based, not a full SQL parser: string literals are protected, but deeply nested subqueries are not re-indented by depth. See the FAQ for what that means.
How it works
What the formatter does
Major clauses — SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, each JOIN variant — start a new line at the left margin. AND, OR and ON are indented one level, as are the items in a select list, so the shape of the query becomes visible at a glance.
Keywords are cased consistently. Uppercase keywords against lowercase identifiers is the dominant convention because it makes the query's skeleton scannable.
String literals are protected
Before any keyword substitution, single-quoted literals are split out and set aside, then restored afterwards. Without that step, a query containing WHERE status = 'selected' would have the word select inside the literal rewritten — a classic bug in naive SQL formatters that silently corrupts your query.
What it deliberately does not do
This is a keyword-driven formatter, not a SQL parser, and it is honest about the consequence: it does not re-indent nested subqueries according to their depth, and it does not know dialect-specific keywords such as Postgres's LATERAL or SQL Server's APPLY. For a complex analytical query with several levels of nesting, use your database client's own formatter. For the common case — a query you pulled out of a log and need to read — this is faster.
What people use it for
- Reading a query from an application log, where an ORM has emitted it as one long line.
- Reviewing a query in a pull request that was written without line breaks.
- Normalising formatting before a diff, so a real change isn't hidden among whitespace.
- Minifying a query to embed in a string literal or a config value.
- Making keyword casing consistent across a file written by several people.
Nothing is uploaded. This tool runs entirely in JavaScript in your browser. Your input is never sent to a server, never logged and never stored, and no account is required. Once the page has loaded you can go offline and it still works — open your browser's network tab and watch if you'd like to confirm it.
Frequently asked questions
Does it understand my SQL dialect?
Partly. It recognises standard SQL keywords plus the common ones across MySQL, PostgreSQL, SQL Server and SQLite. Dialect-specific constructs such as LATERAL or APPLY are not specially handled, though they are left intact.
Will it correctly indent nested subqueries?
No, and this is its main limitation. It breaks lines on keywords rather than tracking nesting depth, so a subquery's clauses align with the outer query's. For deeply nested analytical queries, use your database client's formatter.
Will it break a query containing the word 'select' inside a string?
No. Single-quoted literals are extracted before keyword processing and restored afterwards, so text inside strings is never rewritten. This is a bug in many simpler formatters.
Does it validate my SQL?
No. It reformats text and does not check syntax, table names or column names. Valid-looking output does not mean the query will run.
Is my query uploaded?
No. Formatting happens in your browser, which matters when a query contains real identifiers or literal values from production.
Tools that run where your code is
This page does its work in your browser because sending your data to a server to process it is a bad default. Catalase applies the same idea to AI coding: a free, open-source code editor that runs language models on your own machine through Ollama, with no account and no telemetry. Cloud models are there when you choose one, not by default.
Related tools
- JSON to CSV — Turn query results in JSON into spreadsheet rows.
- Python formatter — Tidy Python indentation and spacing.
- Diff checker — Compare two versions of a query.