AppHelp guide
SQL Formatter vs SQL Minifier Workflows
Learn when to format SQL for review, when to minify SQL for transport, and how to keep query meaning stable while changing whitespace.
Quick answer
Format SQL when people need to read, review, or debug a query. Use minification for simple snippets after checking literals and comments. The current minifier is not a dialect-aware parser: its single-line option also collapses whitespace inside quoted strings.
Format SQL for humans
Readable SQL makes joins, filters, grouping, and nested queries easier to review. Formatting is useful before code review, incident analysis, documentation, and support tickets.
- Break long SELECT lists across lines
- Align JOIN and WHERE clauses for scanning
- Keep parameter placeholders unchanged
Minify SQL for generated output
Minification removes unnecessary whitespace and line breaks. It is useful for generated snippets, copied configuration values, or transport formats where compact output matters.
Protect literals and comments
Whitespace inside string literals is data. Turn off Compress to one line when spaces inside quotes matter. Also turn it off when keeping -- or # line comments: joining lines can make a comment consume the next statement. Keep the original query and review the output before use; dollar-quoted strings and all SQL dialects are not guaranteed.
Frequently asked questions
Does formatting SQL change the query?
A formatter should only change whitespace and indentation outside literals. Query logic should stay the same.
When should I avoid minifying SQL?
Keep the source query. Avoid single-line output when quoted whitespace matters or line comments must remain, and use a dialect-aware parser for complex SQL.