Reformat tangled SQL into readable, clause-per-line queries — keywords upper or lower case, string literals left untouched — entirely in your browser. Runs entirely in your browser — your numbers never leave this device.
Paste a query — the one-line tangle copied out of an application log is the usual case — and the formatter re-lays it out by clause: SELECT, FROM, WHERE, each JOIN, GROUP BY, ORDER BY and LIMIT each start their own line, keywords take the case you choose, and indentation follows the structure. The query is tokenised rather than blindly split on spaces, which is what keeps the dangerous parts safe: a string literal like 'O Neil' is one token and passes through untouched, dotted identifiers like a.id stay joined, and a keyword appearing inside a literal is never mistaken for a clause.
Be precise about what this tool is and is not. It is a layout tool: it changes whitespace and keyword case, and it will faithfully reformat a query that references tables which do not exist or columns nobody defined — it never connects to a database, never executes anything, and does not promise that a reformatted query is syntactically valid for your dialect. Dialects genuinely differ (TOP in SQL Server, LIMIT in PostgreSQL and MySQL, backtick quoting in MySQL), and a layout that suits all of them is a layout that commits to none; check the result against your own engine before it ships.
The working habit this page supports is review: a clause-per-line query is one a colleague can actually read in a pull request, and one whose JOIN conditions and WHERE filters can be checked line by line instead of excavated from a paragraph. Paste queries stay in your browser — nothing is uploaded, which matters when the query embeds real names, emails or account numbers in its literals.
No. It rewrites whitespace and keyword case only — SQL engines ignore both. Table and column names, dotted references, numbers and string literals are copied token for token, as the 'O Neil' example shows: a literal that a naive formatter would split or re-case passes through intact. If a reformatted query returns different results, the difference was already in the text.
No — it is a formatter, not a parser connected to your database. It has no catalogue of your tables and columns, applies no single dialect's full grammar, and will lay out a query that your engine would reject. Run the query against a development database for a verdict; use this page to make the query readable enough to review before you do.
Purely a team convention — engines accept both, and mixed case too. Upper-case keywords (the default here) make clause boundaries jump out of a dense query, which is why most style guides pick it; lower case matches the surrounding code in some codebases. Consistency inside one project matters more than the choice itself, which is why the tool offers upper, lower and keep-as-written.
Opening brackets deepen the indentation of what follows and closing brackets bring it back, so a subquery in a FROM or WHERE clause sits visibly inside its parent statement. Each top-level clause still starts on its own line; the indent is what shows which statement a clause belongs to.
Yes — the clause rules cover the statement families the formatter recognises, including INSERT INTO … VALUES, UPDATE … SET and DELETE … FROM, along with UNION combinations and WITH clauses. A semicolon ends a statement and starts the next on a fresh line, so a pasted script formats statement by statement.
No. Formatting runs 100% in your browser — queries often carry real personal data inside their literals, and none of it leaves your device here.
More in Developer Tools · Browse all tools