SQL formatter

Before / after

Messy one-liners from logs become scannable when major clauses break onto their own lines. Example input:

select u.id,u.email from users u left join orders o on o.user_id=u.id where o.total>100 order by o.created_at desc limit 20; insert into audit(user_id,action) values (1,'login');

After Format with uppercase keywords and 2-space indent, clauses like SELECT, FROM, LEFT JOIN, WHERE, ORDER BY, and LIMIT sit on separate lines, and the INSERT starts a new statement block. Minify does the reverse: collapses runs of whitespace into single spaces while leaving quoted strings alone.

Keyword casing and why teams care

Many style guides uppercase SQL keywords so identifiers stand out in diffs. Turning Uppercase keywords on rewrites recognized keywords (SELECT, JOIN, WHERE, and the rest of the built-in list) without touching string literals or quoted identifiers. Leave it off when your repo already lowercases keywords or when you only want indent and line breaks.

What this formatter will mangle

• Strings that contain keyword-like text are protected when quotes are balanced. Odd escapes or dialect-specific quoting can still confuse the tokenizer.
• Line comments (--) and block comments (/* … */) are preserved, but nested comment edge cases are not a full SQL lexer.
• PL/SQL, T-SQL batches with GO, Postgres dollar-quoting, and heavy CTE nesting may come out merely “better than one line,” not perfect.
• It does not validate grammar. Broken SQL stays broken, just with different whitespace.

Quick workflow

1. Paste the query from a log, ORM dump, or Slack paste.
2. Pick indent size and whether keywords should be uppercased.
3. Hit Format for a PR-ready layout, or Minify for a single-line log/config paste.
4. Copy the result. Clear when you are done so nothing sits on a shared screen.

Pair with JSON Schema validator when the payload next to the query needs a shape check, or hash generator when you need a fingerprint of a query string for cache keys.

FAQ