SQL Formatter

Why SQL formatting matters more than it looks

A SQL query is valid whether it is one cramped line or fifty tidy ones — the database engine does not care about whitespace. But humans do. A query written as a single run-on line hides its own structure: you cannot tell at a glance which tables are joined, what the filter conditions are, or whether that AND belongs to the WHERE or to a JOIN. Formatting makes the logical shape of the query visible. This tool reformats messy SQL so that every major clause starts on its own line, sub-clauses are indented, and keywords are uppercased, turning a wall of text into something you can read, review, and debug.

What the formatter does, step by step

The tool applies a deterministic set of rules entirely in your browser:

• Normalises whitespace. Every run of spaces, tabs, and newlines collapses to a single space, giving the formatter a clean slate.
• Uppercases keywords. Standard keywords — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, LIMIT, and dozens more — are detected case-insensitively and rewritten in capitals. Longer keywords are matched before shorter ones so LEFT JOIN is not partially mangled into LEFT plus JOIN.
• Puts each clause on its own line. Major clause starters (the ones that begin a logical section) break to a new line at the left margin.
• Indents the connectors. A standalone AND or OR in a top-level WHERE is pushed onto its own indented line so multi-condition filters stack vertically.
• Breaks the select list. Commas in the SELECT list start a new indented line, so every column you are fetching is listed one per row.

It is a formatter, not a validator: it never executes your query, never checks it against a schema, and will happily prettify SQL that contains errors. String literals in single, double, or backtick quotes are preserved intact, so a keyword that appears inside a quoted value is not touched.

A worked example

Paste this compact query:

select id, name, email from users where active = 1 and created_at > '2024-01-01' order by name limit 20;

The formatter returns it as a readable block: SELECT on its own line with id,, name,, and email each indented underneath; FROM users on the next line; WHERE active = 1 followed by an indented AND created_at > '2024-01-01'; then ORDER BY name and LIMIT 20; on their own lines. Note that the string literal '2024-01-01' is left exactly as written. The output panel also shows a live line count so you can see how much structure was recovered.

Genuine use cases

• Reviewing someone else's query. Code review of a 200-character one-liner is painful; formatted, the joins and filters are obvious.
• Debugging. When a query returns the wrong rows, laying out each condition on its own line makes a misplaced AND/OR or a forgotten join condition jump out.
• Cleaning up ORM-generated SQL. Logs from ORMs and query builders emit dense single-line SQL; pasting it here makes it legible before you save it as a stored procedure or migration.
• Documentation and tickets. A formatted query reads far better in a wiki, a pull request, or a bug report.

Tips and limitations

• It is dialect-agnostic, not dialect-aware. Standard SQL keywords are formatted, and dialect-specific functions (such as PostgreSQL's JSONB operators or MySQL date functions) are left as-is rather than being broken or renamed. That keeps it safe across MySQL, PostgreSQL, SQLite, and SQL Server, but it will not reformat exotic vendor syntax intelligently.
• Operator precedence still needs parentheses. Formatting clarifies layout, not logic. WHERE a OR b AND c still binds AND tighter than OR; pretty indentation does not change that. Add explicit parentheses when you mean something different.
• Comments and complex nesting are simplified. The formatter targets common statement shapes; deeply nested subqueries may not indent perfectly. Use it as a fast first pass, then tidy edge cases by hand.
• Keep formatting consistent in your repo. Pick one casing and layout convention for checked-in SQL so diffs stay small and reviews stay easy.

All formatting happens locally with JavaScript. Your SQL — which often contains table names, column names, and sometimes embedded values — never leaves your device or touches a server.