SQL Formatter

Overview

Reformats SQL queries into readable, consistently indented form: clauses and joins on their own lines, AND/OR conditions broken out inside WHERE and HAVING, select lists one column per line. Deliberately dialect-neutral and entirely client-side.

How It Works

Paste a query and press Format SQL; the result appears in the read-only pane with a Copy button, and Reset restores the sample query. Your input persists in the browser between visits under a versioned localStorage key, so a long session survives an accidental reload. Comments, quoted strings, and identifiers pass through untouched.

Step-by-Step Usage Guide

1. Paste the query into the input pane.
2. Press Format SQL and read the restructured output.
3. Check vendor-specific syntax — the formatter is dialect-neutral and does not reject what it does not know.
4. Copy the formatted SQL back into your editor or migration.

Technical Specifications & Standards

This is a purpose-built tokenizer rather than the npm sql-formatter package: it recognises a fixed keyword set, understands single-quote, double-quote, and backtick string delimiters including escaped quotes, and treats -- line comments and /* block */ comments as untouchable tokens. Major clauses (SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT, joins, set operations) start a new line at indent level one; commas break lists only outside parentheses, so function arguments stay together; a semicolon resets everything for the next statement.

Targeted Use Cases

• Reviewing a 40-line generated query before letting it anywhere near production.
• Normalising queries copied from ORM logs so code review can actually read them.
• Breaking a sprawling WHERE clause onto separate AND/OR lines for a bug hunt.
• Formatting queries for documentation or a wiki page.

Notes & Gotchas

• There are no options by design: 2-space indent, uppercase keywords, one clause per line. If your team's style differs, format first and restyle locally.
• The formatter does not validate SQL — syntactically broken input is re-formatted without complaint, so read the output for missing commas or keywords.
• It is dialect-neutral: MySQL backtick identifiers, PostgreSQL casts, and T-SQL brackets are tokenised generically, so spot-check dialect-specific constructs afterwards.
• Multiple statements format in sequence — a semicolon resets indentation — but mixed DDL and DML scripts still deserve a scan once formatted.

Frequently Asked Questions