SQL formatter
Format a SQL query so you can actually read it.
Making a query readable
Queries arrive as one enormous line — out of a log, an ORM, or a colleague's message. Formatting puts each clause on its own line, indents subqueries and joins, and lines up the parts so the structure is visible at a glance.
That structure is the point. A five-table join written on one line is unreadable; the same join formatted shows immediately which tables are joined on what, and where a condition has gone missing.
Uppercase keywords
The convention of writing SELECT and FROM in capitals exists to separate the language from your table and column names at a glance. SQL itself does not care. It is on by default because it genuinely helps when scanning, and you can turn it off if your codebase does otherwise.
It is a parser, so it will tell you when the SQL is broken
A query that cannot be parsed is reported with the problem rather than reformatted into something misleading. That is useful on its own — an unbalanced parenthesis or a missing comma in a long SELECT list is far easier to find here than in a database error message.
What it does not do
It does not optimise, validate against a schema, or check that your tables exist. It is a formatter, not a linter — and it does not execute anything, so pasting a DELETE here is entirely safe.
Dialects
Standard SQL formats cleanly, and the common dialects mostly do too. Very vendor-specific syntax — PL/SQL blocks, T-SQL control flow — may format less tidily, because those are closer to programming languages than to queries.
Nothing is uploaded
Queries frequently contain table names, business logic and sometimes literal customer data. None of it leaves your browser.
Common questions
Does it run my query?
No. It only formats text. Pasting a DELETE here is completely safe.
Why did it refuse my SQL?
It parses before formatting, so a syntax error is reported rather than mangled. That usually points straight at the problem.
Should keywords be uppercase?
SQL does not care. The convention separates language from identifiers when scanning, which is why it is the default here.
Does it work with my dialect?
Standard SQL and the common dialects format well. Vendor-specific procedural blocks format less tidily.
Is my query uploaded?
No. It stays in your browser, which matters since queries often contain real data.