SQL Formatter

Why format SQL before sharing or reviewing it?

What this tool does

This SQL formatter beautifies messy queries into readable, indented layouts or minifies them into compact single-line strings. Choose a dialect preset — Standard SQL, MySQL, PostgreSQL, or SQLite — so keywords and syntax quirks align with your database engine. Monaco-powered editors on both sides give you syntax-aware input and copy-ready output.

Why you need it

SQL copied from production logs, ORM debug output, or one-line migration scripts is often unreadable. Nested subqueries without indentation hide logic errors; inconsistent keyword casing makes code review slower. A formatted query lets teammates spot missing JOIN conditions, ambiguous column references, and accidental cartesian products before they reach production.

Minify mode serves the opposite need: shrink a query for logging pipelines, URL parameters, or embedded strings where every byte counts. Because queries may contain table names, customer IDs, or proprietary business logic, keeping formatting local in the browser avoids exposing schema details to external services.

How to use it

1. Paste SQL into the input editor, or click Load sample to see a formatted example.
2. Select the dialect that matches your database from the toolbar dropdown.
3. Click Beautify for indented, multi-line output or Minify for a compact version.
4. Copy from the output editor and paste into your ticket, pull request, or documentation.

Practical examples

• Code review prep: Beautify a teammate’s one-line SELECT before posting review comments on specific JOIN clauses.
• Documentation: Format migration scripts for an internal wiki so readers can follow CTE chains step by step.
• Debugging ORM output: Paste the raw query Django or Hibernate logged, then indent it to see whether the ORM added an unexpected subquery.
• Log compression: Minify a repetitive INSERT batch before storing it in a compact audit trail.

How it works

The formatter uses the open-source sql-formatter library, which tokenizes SQL into keywords, identifiers, operators, and literals, then reassembles them with consistent indentation and line breaks. Dialect presets adjust keyword lists and parsing rules — for example, MySQL backtick quoting versus PostgreSQL double-quote identifiers. Beautify preserves all tokens and only changes whitespace; the database would execute the same plan. Minify removes non-essential spaces and line breaks, though inline comments may collapse depending on placement.

When the parser encounters syntax it cannot handle, the status bar reports the error and the input editor highlights the approximate problem line — similar to the JSON Formatter workflow. Parsing and formatting never leave your browser; no query text is uploaded to Kitnax servers.

Common mistakes

• Wrong dialect: PostgreSQL-specific syntax like ::type casts may confuse the Standard SQL preset. Match the dropdown to your engine.
• Assuming minify is reversible: Minified output loses comments and readable structure. Keep the beautified original as your source of truth.
• Formatting incomplete snippets: A lone WHERE clause without its SELECT cannot parse. Include enough context for a valid statement.
• Trusting formatted output in production without testing: Formatting should not change semantics, but always run formatted migrations in a staging environment first.

FAQ

Related tools

• JSON Formatter
• YAML ↔ JSON Converter
• Diff Checker
• Find & Replace