SQL Formatter

You paste SQL into the input area and the formatter parses it into its component parts (keywords, identifiers, operators, string and numeric literals, comments), then reassembles it using a consistent layout. The core controls are:

• Indentation — choose 2 spaces, 4 spaces, or a tab per nesting level. Subqueries, CASE expressions, and parenthesised groups each indent one level deeper.
• Keyword casing — force reserved words like SELECT, FROM, WHERE, JOIN, GROUP BY to uppercase (the common convention) or lowercase. Your identifiers (users, order_id) are left exactly as you typed them.
• Line breaks — major clauses each start on their own line, and long SELECT column lists and IN (...) sets can be broken one item per line.

The output is syntax-highlighted so keywords, strings, and comments are visually distinct. Formatting is a pure text transformation: it never changes what the query does, only how it reads. Copy the result with one click.

Here is the kind of single-line query you get out of a query log:

select u.id, u.email, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.created_at > '2024-01-01' group by u.id, u.email having count(o.id) > 5 order by orders desc;

Formatted with 2-space indent and uppercase keywords, it becomes:

SELECT
  u.id,
  u.email,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2024-01-01'
GROUP BY u.id, u.email
HAVING COUNT(o.id) > 5
ORDER BY orders DESC;

Now the join condition, the filter, and the aggregate logic are each on their own line, so you can review the query clause by clause instead of parsing one wall of text.

• Reading queries from logs — ORMs and frameworks emit SQL on a single line. Formatting makes a logged slow query reviewable.
• Code review — a beautified query in a pull request is far easier to reason about, and reviewers can spot a missing JOIN condition or an accidental cartesian product.
• Cleaning up before committing — apply one consistent style to migrations and view definitions so the whole repo reads the same way.
• Learning and teaching — a clearly indented query shows nesting and clause order at a glance, which helps when explaining subqueries or window functions.
• Untangling generated SQL — query builders and BI tools produce verbose, deeply nested output; reformatting reveals the actual structure.
• Comparing two queries — format both the same way before a diff so the only differences shown are real logic changes, not whitespace noise.

A formatter rearranges text; it does not understand your database. Keep a few things in mind:

• It does not validate against a schema. A typo in a column name formats cleanly. The tool checks structure, not whether tables or columns exist.
• String literals are preserved verbatim. Text inside quotes, including SQL keywords, is never re-cased or re-indented. WHERE status = 'select' keeps the lowercase select.
• Dialect differences exist. SELECT, JOIN, and WHERE are universal, but vendor-specific syntax (PostgreSQL :: casts, MySQL backticks, T-SQL TOP, bracketed [identifiers]) is handled as generic tokens, so it stays intact but may not get bespoke layout.
• Comments stay where they are. -- line comments and /* block comments */ are kept, though their exact horizontal position can shift.
• One statement or many. Multiple statements separated by ; are each formatted; very large scripts simply take a moment longer.

SQL is case-insensitive for keywords: select, SELECT, and SeLeCt all parse identically. So why do most style guides put reserved words in uppercase? It is purely a readability convention. Uppercasing the keywords (SELECT, FROM, WHERE, INNER JOIN) makes the structure of a statement pop out from the data (your table and column names, which stay lowercase or snake_case). When you scan a long query, your eye lands on the clause skeleton first.

This is the same reasoning behind indenting subqueries: the language does not require it, but a human reading the query benefits enormously. The formatter applies the casing rule only to recognised reserved words. It deliberately leaves identifiers untouched, because object names can be case-sensitive depending on the database and quoting ("MyTable" in PostgreSQL is not the same as mytable). Re-casing those could change meaning, so the tool never does it.

All formatting happens in your browser using JavaScript that ships with the page. Your SQL is never transmitted, logged, or stored anywhere. There is no backend that receives the text, so closing the tab is the only cleanup needed.

This is the practical reason to prefer a client-side formatter for SQL over a server-based one. Production queries leak information about your data model: table names hint at your domain, column names reveal what you collect, WHERE clauses sometimes contain real IDs or values, and join structure exposes relationships. Pasting that into a tool that uploads it means handing a stranger a map of your schema. Because this runs locally, you can format a query copied directly from a production log or an incident channel without that risk. You can verify it yourself: format a query, then disconnect from the network and format another. It still works.