Code Diff Viewer
Compare two files side by side and export a unified diff.
Re-indent a SQL query into readable clauses, joins and conditions.
The SQL Formatter tokenises a query before laying it out, so a keyword inside a string or a column named "order" never confuses it. Clauses get their own lines, joins align, and subqueries indent while function calls stay inline.
A query copied out of an ORM log or an application string arrives as one long line, and reading it is guesswork. The formatter tokenises it properly and lays it out the conventional way: each major clause on its own line, the selected columns indented beneath SELECT, joins with their ON conditions aligned, and AND and OR under the WHERE they belong to.
Tokenising rather than pattern-matching is what makes it reliable. A string literal containing the word "from", a column named "order", a comment holding a semicolon — none of them confuse it, because the formatter knows what each token is before it decides where to break. Subqueries are indented as blocks while function calls stay inline, so count(o.id) is never split across two lines.
String literals, quoted identifiers and comments are recognised as such, so the word "from" inside a string is never treated as a clause.
A parenthesis holding SELECT becomes an indented block; one holding arguments stays inline, so count(o.id) is never split.
AND and OR are indented beneath the WHERE they belong to, and ON sits under its JOIN, which is what makes a long query scannable.
Upper case, lower case, or left exactly as written — and only reserved words are touched, never your column names.
MySQL backticks, standard double quotes and SQL Server brackets are all recognised as identifiers and left alone.
A single query or a script of several statements.
Upper case is the convention; lower case and leave-as-is are also available.
Two spaces, four spaces or a tab.
Paste it into your editor, a migration or a code review.
The formatting is dialect-agnostic. MySQL backticks, PostgreSQL and standard double quotes, and SQL Server square brackets are all recognised as quoted identifiers and left alone.
No. Only whitespace between tokens changes, plus keyword capitalisation if you ask for it. String literals, identifiers and comments are copied through byte for byte.
Because it is a function call, not a subquery. A parenthesis containing SELECT is indented as a block; one containing arguments stays on one line, which is what makes the output readable.
Yes. Statements separated by semicolons are each formatted and separated by a blank line.
What people who use the SQL Formatter think of it. Reviews come from visitors and are posted as written.
No ratings yet
Yours would be the first.
0 reviews
Newest first
No reviews yet
Be the first to rate the SQL Formatter. It takes half a minute and no account.
Write the first reviewCompare two files side by side and export a unified diff.
Generate complete fake user profiles for seeding and design work.
Check any number against the Luhn checksum and see the working.
Compute a CRC-32 checksum in hex, decimal and signed form.
Generate Java POJOs or records with Jackson annotations from JSON.
Convert HTML into valid JSX, with every attribute renamed correctly.
Every HTTP status code, searchable, with what it actually means.
Strip whitespace and optionally comments from XML, and see the bytes saved.