SQL Formatter

What does this formatter do?

It lays out your SQL so a person can read it, and then does something a formatter usually does not: it reads the query back to you for danger.

• Warns before you run it. A DELETE or UPDATE with no WHERE, a TRUNCATE, a DROP. Each one flagged with which statement it is in.
• Detects the dialect from the syntax. Backticks mean MySQL, square brackets and TOP mean SQL Server, $$ and :: mean PostgreSQL, DUAL and NVL mean Oracle. The detected dialect is named on screen, not assumed silently.
• Style you control: keyword case, indent size, and commas leading or trailing.
• Nothing leaves your browser, which matters because real queries carry real table and column names.
• Copy or download the complete formatted query as a .sql file.

The warning that justifies the page

A missing WHERE on an UPDATE or DELETE is one of the most common production incidents there is. The statement is valid, it runs instantly, and it touches every row.

Database clients like DataGrip and DBCode already warn you, and MySQL has a safe-updates mode. All of those protect you at the moment you execute. A formatter is often where a query is first read, reviewed, or pasted from somewhere else, and nothing warns you there. So this page does.

One detail that matters: the check looks at the top level of each statement. A WHERE that only exists inside a subquery does not make an UPDATE safe, and that case is still flagged.

Why the dialect matters

SQL dialects disagree about syntax, and a formatter that guesses wrong can break a statement apart rather than tidy it:

Rather than making you pick from a dropdown and hoping, this page reads those signals and tells you what it found. Override it whenever the guess is wrong.

What this tool does not do

• It does not run anything. There is no database connection, so it cannot tell you whether a query works, is fast, or returns what you expect.
• It does not convert between dialects. Turning MySQL into PostgreSQL means rewriting functions, types and syntax. That is a different and much larger tool.
• The safety check is text analysis, not a guarantee. It reads statements after stripping comments and string contents, which prevents false alarms, but a query built dynamically inside a stored procedure or assembled by an application can still escape it. Treat a clean result as "nothing obvious found", not as approval.
• It does not lint your SQL. No style rules, no performance advice, no naming conventions. Just formatting, dialect detection and the specific dangers above.
• It does not validate syntax. Badly broken SQL may format oddly rather than produce a clear error, because the formatter works on whitespace, not on meaning.

Is my query private?

Yes. The formatting runs through a library loaded into your browser, and the dialect detection and safety checks are our own code running on the same page. No network request carries your SQL anywhere, nothing is logged or stored, and closing the tab clears it. Real queries tend to contain production table names, column names and sometimes values, which is exactly why this one stays on your device.