SQL Formatter

Paste a query and it is laid out straight away.

1. Paste one or more statements into the Input box, or press Paste. Try it loads a short query. Statements separated by semicolons are formatted one after another, with a blank line between them.
2. Pick the Keyword case: UPPER writes keywords such as SELECT and FROM in capitals, lower writes them in lowercase, and Keep leaves them as you typed them.
3. Choose the Indent: 2 spaces, 4 spaces or Tab. It controls how far AND, OR and subqueries are pushed in.
4. Read the status line, which reports how many tokens were formatted.
5. Press Copy or Download .txt, then rename the download to .sql. Use as input moves the result back into the input box.

Quoted text, comments and numbers are never altered, and the query stays in your browser. That is useful when it contains customer identifiers or production table names.

The formatter splits the text into tokens and starts a new line for each major clause: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, OFFSET, INSERT INTO, VALUES, UPDATE, SET, DELETE FROM, UNION, WITH, RETURNING, each kind of JOIN, and ON. AND and OR each begin an indented line under their clause. Given a query with a left join, the result looks like this:

SELECT u.id, u.name, COUNT(o.id) AS n then FROM users u, LEFT JOIN orders o and ON o.user_id = u.id, with AND o.status = 'paid' indented beneath it, followed by WHERE, GROUP BY, HAVING, ORDER BY n DESC and LIMIT 10 on separate lines.

Column lists are not split one per line: they stay on the SELECT line, separated by a comma and a space. A bracketed subquery is indented one level for each bracket depth, so WHERE id IN (SELECT id FROM u) spreads over several lines. Spacing around operators is normalised, so x=1 becomes x = 1.

Keyword case applies to a fixed list of about sixty words: the clause words above plus common ones such as AS, IN, NOT, NULL, DISTINCT, CASE, WHEN, LIKE, BETWEEN and the functions COUNT, SUM, AVG, MIN and MAX. Everything else keeps its case, including data types such as int and varchar and the keyword TOP. Strings, quoted identifiers and comments are never touched, so a value like 'x from y' is safe.

The list is matched on the bare word, so an unquoted column called key, index or default is recased too. Use Keep if your database treats names case-sensitively. Syntax outside plain ANSI SQL is handled less well. Check the output when your query contains:

• A PostgreSQL cast. x::int comes out as x : : int.
• A named parameter or variable. :name and @id get a space after the first character.
• SQL Server bracket identifiers. [col] gets spaces inside the brackets.
• A negative number. -5 becomes - 5.
• ON DUPLICATE KEY UPDATE, which is split over lines because ON and UPDATE both start a clause.

The tool does not parse a grammar, so it will not report a misspelt column or a missing bracket, and it never runs anything. Formatting a DELETE without a WHERE clause is harmless here, which makes it a good place to read a risky statement before you execute it.

Queries that need formatting rarely come from a careful author. They come from ORM debug logs, slow query logs, old stored procedures, report builders and bug reports pasted into chat.

• Expand a one-line query logged by an ORM to see which joins and filters it generated. Placeholders such as ? and $1 are left in place.
• Read a slow query log entry before deciding what to index. Remove any quotes that wrap the whole query first.
• Standardise case and layout before you commit a migration or seed script.
• Format two versions of a changed query so the diff checker shows logic rather than whitespace.

Epoch values in a WHERE clause are easier to reason about after the Unix timestamp converter turns them into dates. When a JSON column or logged payload sits next to the query, the JSON formatter makes it readable, and the UUID generator supplies sample identifiers for test inserts.