Format SQL for code review

Reviewers should not have to parse a 400-character single-line query. Format SQL with consistent keywords, indentation, and line breaks so the diff shows intent, not whitespace.

Open this example in SQL Formatter

Open the tool, then paste the sample input below. Everything runs locally in your browser.

Open this example in SQL Formatter →

The problem

SQL pasted from an ORM log or a quick fix is often one long line with inconsistent casing. In a pull request that is hard to review and produces noisy diffs. Formatting it into a canonical shape makes the logic and any change obvious.

Sample input

Unformatted
select o.id,o.total,c.email from orders o join customers c on c.id=o.customer_id where o.status='paid' and o.total>100 order by o.total desc;

Expected output

Formatted
SELECT o.id, o.total, c.email
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'paid'
  AND o.total > 100
ORDER BY o.total DESC;

Keywords uppercased, one clause per line, and predicates aligned — the WHERE logic is now readable at a glance.

How to do it

  1. Paste the SQL query.
  2. Choose keyword case and indentation.
  3. Format the query.
  4. Review the clause-per-line output.
  5. Copy it into the pull request.

Common mistakes

  • Reformatting SQL that contains a syntax error and assuming the formatter fixed it.
  • Mixing dialect-specific syntax the formatter does not recognize.
  • Letting auto-format change string literals or quoted identifiers.
  • Committing both the one-line and formatted versions in the same diff.
  • Formatting generated SQL that should stay as the ORM emits it.

Related tools

Related guides

FAQ

How do I format SQL for a pull request?

Paste the query, choose keyword case and indentation, and format it. The result puts one clause per line so reviewers can read the logic and the diff stays focused.

Should keywords be uppercase?

Uppercase keywords are a common convention because they stand out from identifiers. Pick the casing your team uses and apply it consistently.

Will formatting change what my query does?

No. Formatting only changes whitespace and casing of keywords, not the query semantics. String literals and quoted identifiers are preserved.

Does it validate the SQL?

Formatting assumes the input parses. If the query has a syntax error, fix it first; the formatter does not execute or validate against a database.

Is my SQL uploaded?

No. Formatting runs locally in your browser. Your query is not sent to a server.

SQL formatting runs locally in your browser. Your query is not uploaded.

Explore more data cleanup and QA tools

Format SQL, compare CSVs, clean lists and build SQL filters — grouped in one place.

View the data cleanup & QA toolkit →

Practical example and expected result

Reviewers should not have to parse a 400-character single-line query. Format SQL with consistent keywords, indentation, and line breaks so the diff shows intent, not whitespace. In practice, this is most useful when you need a quick, repeatable check on a SQL snippet before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is select o.id,o.total,c.email from orders o join customers c on c.id=o.customer_id where o.status='paid' and o.total>100 order by o.total desc.... The expected result should resemble SELECT o.id, o.total, c.email FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'paid' AND o.total > 100 ORDER BY o.to..., with the same important values preserved.

Troubleshooting checklist

  • Confirm you copied the complete SQL snippet and not only a partial line or truncated preview.
  • Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
  • Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
  • Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps