SQL Formatter & Beautifier

How to use the SQL formatter

Format SQL queries for readability — proper indentation, keyword casing, line breaks at clause boundaries. Supports MySQL, PostgreSQL, SQL Server, and Oracle dialect quirks. Runs locally; queries (including ones with sensitive data) never reach a server.

• 1. Paste your query. Multi-statement scripts work too — separate with ;.
• 2. Pick the SQL dialect from the dropdown. Affects keyword recognition (LIMIT vs TOP), function names, and quoting style.
• 3. Choose case style: UPPERCASE (default — keywords stand out in code review), lowercase (a more modern style), or preserve as-typed.
• 4. Tune indentation (2/4 spaces or tabs) to match your team's style guide.
• 5. Click "Format" — output appears below. Click "Minify" for the inverse, useful when embedding SQL into a string literal in code.

Common mistakes to avoid

• Formatting auto-generated SQL from ORMs. The output is rarely human-edited — formatting it just adds noise to PR diffs. Format only the queries you actually maintain.
• Mixing JOIN styles. Pick implicit (FROM a, b WHERE) or explicit (FROM a JOIN b ON) and stick to it. Mixing is a code-smell flagged by senior devs in review.
• Trusting SELECT *. Breaks when columns are added, slows queries by fetching unused data, and obscures what you actually depend on. Always enumerate columns in production code.
• Forgetting WHERE on UPDATE/DELETE. Without it, every row is touched. The classic outage. Many tools (DBeaver, MySQL Workbench) warn — don't dismiss.
• Using string interpolation instead of parameters. WHERE id = ${userId} is SQL injection waiting to happen. Always use parameterized queries (? or
  ).
• Casing inconsistencies. Postgres folds unquoted identifiers to lowercase; MySQL is case-insensitive on Windows but case-sensitive on Linux. Quote identifiers if you care about case.