SQL Formatter

Why a one-line query is hard to read — and how formatting fixes it

SQL written on a single line, or copy-pasted out of a log file, an ORM query builder, or a minified export, is technically correct but slow to read: the eye has to hunt for FROM, WHERE and JOIN buried in the middle of a run-on sentence. A formatter's job is to restore the visual structure that SQL's grammar implies — one clause per line, columns and conditions lined up under a consistent indent — without changing what the query does. Paste a query above and it is tokenized, reflowed around its keywords, and re-rendered with your chosen indent width and keyword casing.

How the line-breaking rules work

The formatter walks the query token by token and applies a small set of consistent rules:

• Clause keywords — SELECT, FROM, WHERE, JOIN (and INNER/LEFT/RIGHT/FULL/CROSS JOIN), GROUP BY, HAVING, ORDER BY, LIMIT, UNION and similar — always start a new line at the query's base indent.
• Column and value lists — every top-level comma inside a SELECT list, GROUP BY list, ORDER BY list, an UPDATE's SET list, or a VALUES list starts a new indented line, so a ten-column SELECT is as easy to scan as a two-column one.
• Conditions — AND and OR inside WHERE, ON and HAVING each get their own indented line, except the AND that belongs to a BETWEEN ... AND ... range, which is correctly kept on the same line as its BETWEEN.
• Subqueries — a parenthesis that opens with SELECT or WITH is expanded onto its own indented block, so a subquery in a FROM, an IN (...), or a SELECT list reads like a small, separately formatted query.
• Function calls and grouping — a plain parenthesis such as COUNT(*), IN (1, 2, 3), or OVER (PARTITION BY ... ORDER BY ...) is kept inline instead of being split apart, because these are short expressions rather than clauses.

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

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

Keyword case: UPPERCASE, lowercase, or Unchanged

Reserved words are the only thing the case option touches. UPPERCASE gives the classic textbook look many style guides recommend (SELECT ... FROM ... WHERE ...); lowercase reads a little more compact and matches how many query builders emit SQL; Unchanged reindents the query without touching a single letter's case, useful when a linter or teammate cares about a specific style already in the file. Table names, column names, aliases, and anything inside quotes are always left exactly as typed, because in a case-sensitive database (PostgreSQL's quoted identifiers, for example) changing that casing could silently point at a different column.

Minify: the opposite of formatting

Minify mode strips comments and collapses the query to a single line with only the whitespace SQL actually needs between tokens — handy for embedding a query string in application code, a curl command, or a URL parameter where extra newlines and indentation just waste space. Because it runs through the same tokenizer as formatting, quoted strings, doubled '' escapes, and quoted identifiers pass through byte-for-byte; only the surrounding formatting is removed, never the query's literal values.

What the tokenizer protects — and its honest limits

Before any line-breaking happens, the input is split into strings ('...', with the standard '' escape for an embedded quote), quoted identifiers ("..."/`...`/[...]), line comments (--) and block comments (/* ... */), numbers, operators, and words. Only words that match a list of common SQL reserved keywords are ever recased or used to decide where a line breaks — everything inside a string, comment, or quoted identifier is copied through untouched, so a comment that happens to contain the word SELECT, or a column literally named "order", won't be misread as a keyword.

That said, this tool is a formatter for readability, not a full parser or validator: it doesn't check whether a query is syntactically valid, doesn't know every keyword or function of every dialect (MySQL, PostgreSQL, SQL Server, SQLite, BigQuery and others all differ slightly), and complex nested expressions can occasionally format less elegantly than a hand-tuned style. If something looks off, the Unchanged case option plus a quick scroll through the output usually makes the cause obvious — and nothing about your query ever leaves your browser to be checked anyway.