infoOverview

ORM-generated queries and anything pulled from a slow-query log tend to come out as a dense single line, which makes catching a missing JOIN condition or a redundant subquery much harder than it should be. This formatter re-indents JOIN, WHERE, GROUP BY, and similar clauses onto their own lines so the query's structure is visible at a glance, which speeds up both code review and writing documentation.

Manually re-indenting a query by hand gets old fast, especially once a SELECT list stretches past a dozen columns or a subquery is buried three levels deep. Offloading that grunt work here means you spend your attention on reviewing the logic or tuning the query, not counting spaces.

checklistHow to Use

1. 1Paste the query — copy it straight from your ORM's debug log if that's easier.
2. 2Pick 2 or 4 spaces under Indentation to match your team's style guide.
3. 3Under Mode, choose Standard Format for normal readability, Right-aligned/Tabular if you want keywords lined up in a column, or Minify to flatten everything to one line.
4. 4Set Keywords and Identifiers independently to Uppercase, Lowercase, or Preserve, depending on your house style for SQL casing.
5. 5Hit Format and the cleaned-up query appears on the right, ready to copy into a review comment or doc.

Tip: you can paste several semicolon-separated statements at once — useful for reviewing a whole migration file's worth of CREATE TABLE statements in one pass.

menu_bookSpecifications & Glossary

• Mode: Formatting method selection
  • Standard Format: The familiar style most style guides recommend — each clause on its own line, indented under the keyword it belongs to.
  • Right-aligned/Tabular: Right-justifies keywords so SELECT, FROM, WHERE, and friends line up in a vertical column — a layout some teams (and some legacy style guides) prefer over Standard Format.
  • Minify: Removes line breaks and extra spaces, compressing to a single line.
• Keywords: SQL keyword upper/lower conversion
  • Uppercase: Converts all SQL keywords such as SELECT and FROM to uppercase.
  • Lowercase: Converts all SQL keywords to lowercase.
  • Preserve: Preserves the original casing of the input.
• Identifiers: Controls casing for table and column names independently from keywords — set it to Uppercase, Lowercase, or Preserve to match your schema's naming convention.
• Indentation: Sets the number of spaces used for indentation in the output SQL (e.g., 2 spaces, 4 spaces).
• Supported SQL dialects: This tool formats the standard SQL constructs shared across MySQL, PostgreSQL, and SQLite — SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, and the like. Dialect-specific extensions such as PL/pgSQL stored procedures or T-SQL's BEGIN...END blocks fall outside that common ground and may not format cleanly.
• Comments: Line comments (--) and block comments (/* */) carry over into the formatted output in place, including the bind-parameter comments an ORM often attaches to generated queries.

lightbulbUse Cases

• Cleaning up a query before opening a pull request, so reviewers spend their time on logic instead of deciphering formatting.
• Untangling a query an ORM (Sequelize, Prisma, ActiveRecord, etc.) generated, especially once it includes several joined tables.
• Producing a clean SQL snippet to drop into a runbook, wiki page, or onboarding doc.
• Sorting out SQL where an ORM has interleaved bind-parameter placeholders or auto-generated comments with the actual clauses — a common source of "why won't this query format right" confusion that a plain text editor can't fix.
• Formatting a dense multi-table join, e.g. `SELECT * FROM orders o JOIN users u ON o.user_id = u.id JOIN items i ON o.item_id = i.id WHERE...`, to check each JOIN condition lines up correctly while tuning performance.
• Making a raw entry from the slow query log readable as a first pass, before diving into the query plan with EXPLAIN.

quizFAQ

Which SQL dialects does this support: MySQL, PostgreSQL, SQL Server?

It handles the standard SQL syntax shared across MySQL, PostgreSQL, and SQL Server. Dialect-specific extensions — PL/pgSQL procedures, T-SQL's BEGIN...END blocks, MySQL backtick identifiers — can format unexpectedly, so double-check the output before using it.

Is the table and column data in my pasted SQL sent to a server?

No. Formatting happens entirely client-side, so a query is never sent anywhere else — even one that reveals your production schema.

Can it format stored procedure or trigger definitions?

Not reliably — the formatter targets plain DML/DDL statements, so procedural control flow inside stored procedures or triggers (IF, LOOP, CURSOR) may not come out right. Extract just the query body, like the SELECT statement, instead.

Can I format multiple SQL statements at once?

Yes. Paste several semicolon-separated statements at once and each one is formatted on its own — handy for a migration file with a string of CREATE TABLE statements.

When is Right-aligned/Tabular mode useful?

It right-aligns SELECT, FROM, WHERE, and similar keywords into a vertical column, which makes the overall structure of a long, clause-heavy query easier to scan at a glance. It's also a common choice when dropping SQL into documentation or a slide deck.

Why did the output change the casing of my keywords?

That happens automatically whenever Keywords is set to Uppercase or Lowercase — SELECT, FROM, and the rest get converted accordingly. Set it to Preserve if you want the casing you typed to stay untouched.