A query that arrives as one 400-character line is unreadable, and unreadable queries hide bugs. This tool parses your SQL and lays it out with each clause on its own line. It parses rather than merely indents, which is why it can tell you when something is wrong — and why picking the right dialect matters.
The dialect selector is not decoration
SQL is a standard that nobody implements exactly, and the differences start with something as basic as quoting a name. MySQL and MariaDB wrap identifiers in backticks. PostgreSQL uses double quotes and rejects backticks outright. SQL Server uses square brackets. A query written for one and parsed as another does not merely format oddly — it fails.
You can see this here. Paste a MySQL query with backticked column names, select PostgreSQL, and the output goes empty: the parser has correctly refused to read backticks as PostgreSQL, because they are not. That is the tool telling you something true about your query, not malfunctioning.
The differences run deeper than quoting. Row limits are LIMIT in MySQL, PostgreSQL and SQLite, TOP in SQL Server, and FETCH FIRST in the actual standard. String concatenation is || almost everywhere and CONCAT() in MySQL, where || means logical OR unless a specific mode is enabled. If you are moving a query between engines, these are the joints where it will crack.
Formatting checks syntax, not truth
Give this tool a query full of nonsense and it will show you an error, because it genuinely parses the text. That is useful, and it is also the limit of what it can tell you. A query can be perfectly well-formed and still catastrophically wrong.
It cannot know whether your tables exist, whether the column you joined on is indexed, whether that JOIN will return the rows you expect or fifty million of them. A clean format is not a code review. What formatting does buy you is the ability to see the shape of the query — and once a query is laid out, a missing join condition or a WHERE clause that lost its parentheses tends to become visible in a way it never is on one long line.
A formatter is not a security tool
This deserves saying plainly because the confusion is real. Formatting your SQL does nothing whatsoever about SQL injection. It does not escape anything, it does not validate anything, and a query built by gluing user input into a string is exactly as dangerous formatted as it was unformatted — it is just easier to read while it deletes your table.
The only real defence is parameterised queries: the SQL text and the values travel separately, so a value can never be reinterpreted as syntax. Every mainstream driver supports this. If you find yourself reaching for an escaping function, that is usually a sign the query is being built the wrong way round.
Keywords are case-insensitive; identifiers are the trap
SELECT, select and SeLeCt are the same keyword to every engine, so the uppercase option here is pure style — a widespread convention that makes the structure scannable, and nothing more. Nobody will thank you for lowercase keywords, and nothing will break either.
Identifier case is where real bugs live. PostgreSQL folds unquoted identifiers to lowercase, so SELECT MyColumn actually asks for mycolumn — and if you created the column as "MyColumn" with quotes, it will not be found. The standard says identifiers fold to uppercase, so PostgreSQL is technically non-conforming here and everyone has quietly agreed to live with it.
MySQL is stranger still: whether table names are case-sensitive depends on the filesystem underneath the server. Tables are files, so on Linux they are case-sensitive and on Windows and macOS they are not. This is the mechanism behind a specific and miserable class of bug — a query that works on a developer's Mac and fails in production on Linux, with nothing in the code to explain it.
Common questions
Is my query sent to a server?
No. This tool is marked "client": the parser runs in your browser tab and the SQL never leaves your machine. That matters more here than for most tools, because real queries carry table names, column names and often literal values from production — the shape of your schema is information you probably do not want to hand to a stranger.
Will formatting change what my query does?
No. Whitespace between SQL tokens is not significant, so the reformatted query is the same query. The one thing to watch is string literals: text inside quotes is data, and a formatter must leave it untouched. This one does. If you ever meet a formatter that reindents inside a string, stop using it immediately.
Why does my query show an error here but run fine in my database?
Most likely the dialect. Select the engine you actually use rather than Standard SQL — engines accept plenty of things the standard does not. It can also be a genuinely engine-specific extension the parser does not model, in which case the query is fine and the tool is simply not the authority on it. Your database is.
Should I use uppercase keywords?
It makes no difference to the engine. The convention exists because it separates the language from your data at a glance: in SELECT name FROM users, the uppercase words are SQL and the lowercase ones are yours. Most teams follow it, and the useful rule is to match whatever is already in your codebase rather than to have an opinion.
Can it format a stored procedure or a big migration script?
It handles multiple statements and will separate them for you. Procedural extensions — PL/pgSQL, MySQL stored routines, T-SQL control flow — are a different language layered on top of SQL, and support for them varies by dialect. If a procedure body comes back looking mangled, that is the boundary you have hit, and the answer is to format the queries inside it rather than the whole routine.