How to Format
SQL Queries

How to format SQL queries properly is one of those skills that separates "I can write a SELECT" from "I can debug a 40-line JOIN at 2am." Raw or ORM-generated SQL arrives as a single ugly line with no indentation, and the first thing any experienced developer does is run it through a formatter. This guide covers the safe, free way to do it — including what most online formatters do with your query that you probably didn't realise.

Why "Online SQL Formatter" Is a Privacy Question

Most online SQL formatters upload your query to their server for processing. That's usually invisible to you — you paste, click Format, get a response — but it means your SQL (including table names, column names, and sometimes literal values from WHERE clauses) has been transmitted to a third party and logged somewhere. For a throwaway SELECT that's fine. For a production query, it's schema disclosure.

This matters more than it sounds. SQL queries reveal a surprising amount about your database schema — the tables you have, how they relate, your naming conventions, and occasionally real IDs or business logic embedded in query literals. A client-side formatter removes this concern entirely by doing the work in your browser.

Step 1 — Open the SQL Formatter

Go to the SQL Formatter. The page loads in your browser — no account, no installation, and no network request is made when you format a query. You can verify this yourself with DevTools → Network tab before pasting.

Step 2 — Paste Your SQL

Drop your SQL into the left input pane. The tool accepts:

Step 3 — Pick Your Dialect

Different SQL dialects format slightly differently — keyword casing, function names, quoted identifier style, and dialect-specific syntax like RETURNING or LIMIT ... OFFSET. Select the dialect that matches your database:

If you're not sure, MySQL is a reasonable default for ANSI-compatible queries and ORM output. PostgreSQL handles RETURNING, ::cast syntax and array types that MySQL formatting would choke on.

Step 4 — Copy the Formatted Output

Click Format. The beautified query appears on the right pane with:

• Uppercase keywords (SELECT, FROM, WHERE, JOIN)
• One clause per line with consistent indentation
• Aligned AND / OR conditions
• Subqueries indented one level deeper than the outer query
• Comments preserved in place

Copy the result back to your IDE, query tool, or wherever you need it. The tool never saves or transmits the query — once you close the tab it's gone.

Example: Before and After

SELECT "user"."id","user"."email","order"."id","order"."total" FROM "user" INNER JOIN "order" ON ("order"."user_id" = "user"."id") WHERE ("user"."active" = true AND "order"."total" > 100) ORDER BY "order"."created_at" DESC LIMIT 20

SELECT
  "user"."id",
  "user"."email",
  "order"."id",
  "order"."total"
FROM "user"
INNER JOIN "order"
  ON ("order"."user_id" = "user"."id")
WHERE (
  "user"."active" = TRUE
  AND "order"."total" > 100
)
ORDER BY "order"."created_at" DESC
LIMIT 20

The formatted version isn't magic — it's the same query. But now you can see the JOIN condition, the WHERE filters, and the ORDER BY clause at a glance instead of scrolling horizontally through a single line.

Common Gotchas When Formatting ORM SQL

When the Formatter Can't Help

Formatting makes SQL readable, not correct. A few situations where formatting is beside the point:

• Syntax errors. The formatter accepts most malformed SQL but won't tell you what's wrong with it. Run it through your database's parser for real errors.
• Performance problems. A nicely formatted 20-table JOIN is still a 20-table JOIN. Use EXPLAIN to understand execution plans.
• Dialect-specific features you selected incorrectly. Formatting Oracle SQL as MySQL will produce output but may strip or reposition Oracle-only syntax. Pick the right dialect.

For ORM-specific formatting workflows — particularly Django — see How to Format SQL from Django ORM Output.

FAQ