SQL Formatter
Lay out a query so you can read the joins.
About this converter
Queries arrive as one long line — out of a log, an ORM, a stack trace — and the joins are unreadable until they are laid out.
The dialect matters more than it looks. Quoting, which words are reserved, and which functions are recognised all differ, so formatting a T-SQL query as standard SQL can misread an identifier. Standard SQL is a reasonable default and wrong often enough to be worth the menu.
The query is parsed, not pattern-matched, so a string containing a semicolon or two dashes does not confuse it — which is exactly where a regular expression falls over.
Frequently asked questions
Does formatting change what my query does?
No. Only whitespace, line breaks and keyword capitalisation change. SQL keywords are case-insensitive, so capitalising them is cosmetic — identifiers and string literals are left exactly as they are, which is the part that would matter.
Which dialect should I choose?
The one your database speaks. It affects how identifiers are quoted and which words are treated as keywords, so a query with a column called "user" or a T-SQL bracket quote can format oddly under the wrong setting. Standard SQL handles ordinary queries across all of them.
Can it format a query with parameters in it?
Yes, but the dialect has to match — placeholder syntax belongs to the database rather than to SQL. $1 parses under PostgreSQL and nowhere else; :name works under most dialects but not MySQL; ? is the most widely accepted. A query pulled out of application logs usually needs its own dialect selected above, and the error says so when that is the problem.
Does what I paste get sent anywhere?
No. Everything runs in your browser, on your own machine. Nothing is uploaded and nothing is logged. That matters more here than on most pages — source code, database queries and internal data are exactly the things that get pasted into tools like this, and most of them are a form that posts to a server.