SQL Formatting, Beautifying, and Writing Cleaner Queries

SQL is the language every developer eventually has to deal with, whether they chose it or not. But raw SQL from a log file, a legacy codebase, or a query builder output is often unreadable — a single line of 400 characters with no indentation, mixed casing, and no structure. Debugging it means reformatting it first.

This guide covers SQL formatting, beautification, and the habits that keep queries readable from the start.

Why SQL formatting matters

A well-formatted SQL query is easier to read, easier to review in a pull request, and easier to debug when something goes wrong. The difference between a single-line query and a properly indented one is not cosmetic — it is the difference between seeing the structure of a query and having to parse it mentally character by character.

Consistent formatting also makes performance issues easier to spot. A missing index condition, an accidental cross join, or a subquery that runs once per row are all much harder to see in minified SQL.

Basic formatting rules

The conventions most teams use are straightforward. Write SQL keywords in uppercase: SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY. Put each major clause on its own line. Indent the columns in a SELECT list, the conditions in a WHERE clause, and the tables in a JOIN.

SELECT
    u.id,
    u.name,
    u.email,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at >= '2026-01-01'
    AND u.status = 'active'
GROUP BY u.id, u.name, u.email
ORDER BY order_count DESC
LIMIT 50;

This is immediately readable. The same query as a single line is not. Use the SQL Formatter to go from one to the other instantly — paste minified or messy SQL and get properly indented, keyword-uppercased output in one click.

Formatting output from ORMs and query builders

Laravel's Eloquent, Django's ORM, and similar tools generate SQL that is technically correct but often difficult to read. When you enable query logging and dump the generated SQL, you get something like this:

select `users`.*, `roles`.`name` as `role_name` from `users` inner join `role_user` on `role_user`.`user_id` = `users`.`id` inner join `roles` on `roles`.`id` = `role_user`.`role_id` where `users`.`deleted_at` is null and `users`.`active` = 1 order by `users`.`created_at` desc limit 25 offset 0

Paste that into the SQL Formatter and it becomes readable immediately. This is especially useful when optimising a slow query — you need to see the structure before you can reason about indexes and join order.

Common SQL mistakes that formatting reveals

Implicit cross joins. A missing ON clause or a comma-separated table list in the FROM clause produces a cartesian product. This is catastrophic on large tables and invisible in minified SQL. Proper formatting makes the join structure obvious.

WHERE clause ordering. Conditions in a WHERE clause should filter as many rows as possible as early as possible. Formatting the clause with one condition per line makes it easy to review ordering and spot missing indexes.

Subquery sprawl. Correlated subqueries that run once per row are a common performance problem. They are nearly invisible in single-line SQL but stand out immediately in formatted output.

Keyword casing inconsistency. Mixing select, SELECT, and Select in the same codebase is a code style problem. The SQL Formatter's uppercase keywords button fixes this across an entire query in one step.

Comparing versions of a query

When you optimise a query, you want to see exactly what changed between the original and the rewritten version. Format both queries first, then paste them into the Diff Checker. The line-by-line diff shows exactly which clauses changed, which conditions were added, and which joins were restructured.

This is particularly useful when reviewing a pull request that claims to optimise a query — you can see the structural difference immediately rather than reading through two versions mentally.

Writing clean SQL from the start

Formatting after the fact is useful but fixing it at the source is better. A few habits make a difference. Always name your aliases explicitly with AS. Always qualify column names with their table alias when joining more than one table. Always write explicit JOIN syntax rather than comma-separated tables. Always put the most selective WHERE condition first.

For JSON data stored in SQL columns, the JSON Formatter handles formatting that content separately — useful when debugging queries that return JSON columns from PostgreSQL or MySQL 5.7+.

Tools

• SQL Formatter & Beautifier — format, indent, and uppercase SQL keywords instantly
• Diff Checker — compare original and optimised query versions line by line
• JSON Formatter — format JSON data returned from or stored in SQL columns