How to Format & Pretty Print SQL Queries — Step by Step

You are staring at a 200-character SQL one-liner in a pull request. It joins three tables, has four WHERE conditions, and a subquery. You cannot tell what it does without reformatting it. Here is exactly how to turn messy SQL into something readable in under 10 seconds.

Step 1: Copy the Messy SQL

Grab the unformatted SQL from wherever it lives:

• A pull request on GitHub or GitLab
• A Slack message from a coworker
• A log file or error message with inline SQL
• Legacy code with queries crammed into single lines
• A database migration file with no formatting
• A stored procedure that has not been touched in three years

Step 2: Paste and Format

Open SQL Formatter, paste the query, and click format. The formatter applies these rules automatically:

Rule	What It Does	Why It Matters
Uppercase keywords	SELECT, FROM, WHERE, JOIN, GROUP BY in caps	Keywords stand out visually from table/column names
One clause per line	Each major clause starts on a new line	You can scan the query structure top to bottom
Indent subqueries	Nested queries get indented inside parentheses	Nesting level is immediately visible
Align JOIN conditions	ON clauses indented under their JOIN	Clear which tables connect and how
One column per line	SELECT columns each on their own line	Easy to add, remove, or comment out columns
Break WHERE conditions	Each AND/OR on its own line	Spot individual conditions instantly
Consistent spacing	Spaces around =, >, <, AND, OR operators	No cramped or uneven spacing

Step 3: Read the Formatted Result

Here is a real example of the transformation:

Before — 200-character one-liner:

select e.id, e.name, d.department_name, m.name as manager_name, count(p.id) as project_count from employees e join departments d on e.dept_id = d.id left join employees m on e.manager_id = m.id left join project_assignments pa on e.id = pa.employee_id left join projects p on pa.project_id = p.id where e.status = 'active' and d.region = 'US' and e.hire_date > '2024-01-01' group by e.id, e.name, d.department_name, m.name having count(p.id) > 2 order by project_count desc;

After — formatted 25-line query:

SELECT e.id, e.name, d.department_name, m.name AS manager_name, COUNT(p.id) AS project_count FROM employees e JOIN departments d ON e.dept_id = d.id LEFT JOIN employees m ON e.manager_id = m.id LEFT JOIN project_assignments pa ON e.id = pa.employee_id LEFT JOIN projects p ON pa.project_id = p.id WHERE e.status = 'active' AND d.region = 'US' AND e.hire_date > '2024-01-01' GROUP BY e.id, e.name, d.department_name, m.name HAVING COUNT(p.id) > 2 ORDER BY project_count DESC;

Same query. Same result set. Now you can see: five columns selected, four table joins, three filter conditions, grouping with a HAVING clause, sorted by project count. That took 5 seconds instead of 5 minutes of mental parsing.

SQL Formatting Conventions to Follow

There is no universal SQL style standard, but these conventions are widely accepted and help teams stay consistent:

1. Uppercase reserved words — SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, HAVING, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP. Lowercase for table and column names.
2. Indent continuation lines — columns in SELECT, conditions after WHERE, ON clauses under JOIN. Standard indent: 4 spaces.
3. One column per line in SELECT — prevents horizontal scrolling and makes column changes easy to spot in diffs.
4. Leading AND/OR — place AND and OR at the start of the next line, not at the end of the current line. This makes it easy to comment out individual conditions.
5. Alias consistently — if you alias one table, alias them all. Short meaningful aliases (e = employees, not e = some_table).

Tips: Format Before Sharing

• Before committing to Git — formatted SQL produces cleaner diffs. One column change shows as one line in the diff, not a massive single-line change.
• Before pasting in Slack — your coworkers will thank you. Formatted SQL in a code block is 10x more useful than a wall of text.
• Before code review — reviewers can focus on logic, not deciphering formatting. Use Diff Checker to compare old vs new query versions.
• Before documenting — queries in documentation or wikis should be readable without reformatting. Format once, paste the clean version.

What Formatting Does NOT Fix

Formatting improves readability, not correctness:

• A typo (SELCT) stays a typo — the formatter does not validate syntax
• A wrong JOIN condition formats beautifully but still returns wrong results
• Missing indexes are not a formatting problem — they are a performance problem
• N+1 query patterns look fine formatted. Use code review for logic issues.

Developer Toolkit

• SQL Formatter — beautify and indent SQL
• JSON Formatter — format JSON data and API responses
• Code Formatter — format application code
• Diff Checker — compare query versions side by side
• Regex Tester — test patterns for SQL LIKE alternatives