SQL Formatter
Format messy SQL queries with proper indentation and keyword highlighting. Options for uppercase keywords and indent size. Supports SELECT, JOIN, WHERE and more.
Why Formatted SQL Catches Bugs Faster
Unformatted SQL is one of the worst things to debug because the syntax is dense and the errors are subtle. A missing comma, a JOIN with a wrong key, or a GROUP BY that's missed a column can hide in a 30-line query that looks like one big run-on sentence. The SQL Formatter restructures the query with proper indentation, uppercase keywords, and aligned clauses so the structure is visible at a glance. Format any query before reading it; the few seconds you spend pasting and clicking save you minutes of squinting.
Most professional SQL editors (DataGrip, DBeaver, pgAdmin, Postico) have built-in formatters; this tool is for the moments when you're staring at a query in Slack, an email, a Stack Overflow answer, or a logged error message. Paste, format, read. The formatter handles SELECT, INSERT, UPDATE, DELETE, JOIN variants (INNER, LEFT, RIGHT, FULL OUTER), CTEs (WITH ... AS), window functions, and subqueries.
Common SQL Formatting Conventions
| Convention | Example | Why |
|---|---|---|
| Uppercase keywords | SELECT, FROM, WHERE | Distinguishes SQL syntax from data |
| One column per line | SELECT a,\n b,\n c | Easier to spot missing commas |
| JOINs on new lines | FROM users\nJOIN orders ON ... | Each table relationship visible |
| WHERE clauses indented | WHERE x = 1\n AND y = 2 | Logical structure clearer |
| 2-space or 4-space indent | Either, but consistent | Matches team style guide |
Reading EXPLAIN Plans Alongside Formatted SQL
Once a query is formatted readably, the next debugging step is running EXPLAIN (or EXPLAIN ANALYZE in Postgres, EXPLAIN PLAN FOR in Oracle, EXPLAIN FORMAT=JSON in MySQL) to see how the database engine intends to execute it. Look for sequential scans on tables that should hit an index, nested loop joins on large tables (usually a missing index), and large estimated row counts that don't match reality (often a stale ANALYZE statistics issue). A query that looks slow to you isn't necessarily slow to the engine; EXPLAIN tells you the truth.
GROUP BY queries are the most common source of subtle bugs: every column in SELECT that isn't aggregated must appear in GROUP BY, or you get either a syntax error (Postgres, strict MySQL) or silently wrong results (loose MySQL). Format the query first, scan the SELECT list and GROUP BY list side by side, and check they match. Pair this with the [JSON Formatter](/json-formatter) when working with JSONB columns, and the [Password Generator](/password-generator) for database connection passwords.
Frequently Asked Questions
Why are SQL keywords uppercase by convention?
It's a long-standing readability convention rather than a syntactic requirement. SELECT and select are equivalent to the SQL parser, but uppercase keywords make the query's structural elements (SELECT, FROM, WHERE, GROUP BY) visually pop out from the column and table names. Most style guides require uppercase keywords for legacy compatibility and code reviews.
Should I put each JOIN on a new line?
Yes, every JOIN on its own line with the ON clause inline. This makes table relationships visible at a glance: 'this table joins to that table on this key'. For complex queries with five or more JOINs, placing each ON clause on a separate indented line improves readability further but is less universally adopted.
How do I format a SELECT with many columns?
One column per line, all aligned, with the comma at the end of each line (the standard) or at the start of each line (Postgres/legacy style, harder to maintain). Many teams put SELECT on its own line and indent the column list under it. The SQL Formatter applies your chosen indent (2-space or 4-space) consistently.
Does the formatter handle CTEs and window functions?
Yes. CTEs (WITH name AS (...)) get their own block with the inner SELECT formatted independently. Window functions (OVER (PARTITION BY ... ORDER BY ...)) get the contents of the OVER clause indented for readability. Both work the same way in Postgres, MySQL 8+, SQL Server, and Oracle.
Why does my formatted SQL still produce errors?
The formatter doesn't validate the SQL, only structures it. Missing tables, wrong column names, type mismatches, or grammar errors will still produce database errors when you run the query. After formatting, run the query through your database's EXPLAIN to validate logic, or paste it into a SQL linter (sqlfluff, sqlcheck) for static analysis before execution.
Related Tools
JSON Formatter & Validator
Format, minify and validate JSON with syntax highlighting. Shows error locations, key count, nesting depth and size stats
CSS Minifier
Minify CSS by removing comments, whitespace and unnecessary characters. See original and minified size with savings percentage. Copy or download the result.
JavaScript Minifier
Minify JavaScript by removing comments and collapsing whitespace. See compression statistics with original and minified size comparison.