SQL Formatter — Beautify & Format SQL Queries
Format and indent SQL queries for readability. Keywords are placed on new lines automatically.
About SQL Formatter — Beautify & Format SQL Queries
SQL Formatter beautifies and indents raw or minified SQL queries in real time, supporting SELECT, INSERT, UPDATE, DELETE, JOIN, subqueries and more. Control keyword case and indent width. Copy to clipboard or download as a .sql file — no sign-up required.
How to Use
- 1Paste your SQL query into the left input area. The formatted output appears on the right instantly.
- 2Choose keyword case — UPPERCASE (SELECT) or lowercase (select) — from the toolbar.
- 3Select indent width: 2 spaces, 4 spaces, or tab.
- 4Click "Copy" to copy to clipboard or "DL" to download a formatted .sql file.
Features
- Real-time formatting — results appear as you type
- Supports SELECT, JOIN, subqueries, and other major SQL constructs
- One-click keyword case unification for team style consistency
- Flexible indent width: 2 spaces, 4 spaces, or tab
- Runs entirely in your browser — no upload, no sign-up required
SQL Formatting Standards
Consistent SQL formatting makes queries easier to read, review, and maintain. Adopting a team standard and applying it uniformly eliminates style debates in code review.
Keyword Casing Conventions
SQL keywords are case-insensitive by the standard, but teams typically adopt one of two conventions: UPPERCASE keywords (SELECT, FROM, WHERE, JOIN, AND) or all-lowercase keywords. UPPERCASE is the traditional style used in most SQL textbooks and documentation, making keywords visually distinct from table and column names. Lowercase is preferred by some modern teams who find it easier to type and less visually loud. Whichever convention your team chooses, enforce it consistently using this formatter — the most important thing is that all queries in a codebase follow the same style.
Indentation for Subqueries and Clause Alignment
Well-formatted SQL places each major clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY) on its own line, with a consistent indent for continuation lines. Subqueries should be indented one level relative to the outer query to show nesting clearly. JOIN clauses should start on new lines at the same level as FROM, with the ON condition indented one level. AND and OR conditions in WHERE clauses should be placed at the start of new lines, not at the end of the previous line, making it easy to comment out individual conditions during debugging.
Readable SQL for Teams
SQL that is easy to read reduces bugs, speeds up code review, and helps new team members understand query logic quickly. These practices go beyond formatting rules to make queries self-documenting.
Meaningful Aliases and Self-documenting Queries
Table aliases like u for users, o for orders, and p for products are widely understood shortcuts. Avoid single-letter aliases like t or a for ambiguous tables — they save keystrokes but make the query harder to read weeks later. Column aliases in SELECT should use descriptive names that match the application's field naming convention, such as u.created_at AS user_created_at when joining multiple tables with date columns. Adding a brief comment above complex queries explaining their business purpose helps teammates understand context without reading every line of logic.
Formatting for Code Review
SQL embedded in application code (as string literals or ORM raw queries) should be formatted consistently before committing. This makes git diffs readable — a diff that changes only the WHERE condition is easy to review; one that reformats the entire query is not. Store complex queries in dedicated SQL files or view definitions rather than inline strings when possible. For migration files, always format SQL before committing so that reviewers can focus on the logic change rather than style inconsistencies.
FAQ
- Which SQL dialects does it support?
- The formatter works with standard SQL and is compatible with MySQL, PostgreSQL, SQLite, Oracle, and SQL Server syntax. Some dialect-specific syntax like stored procedures may not format perfectly.
- Can it format queries with JOINs and subqueries?
- Yes. INNER JOIN, LEFT JOIN, RIGHT JOIN and nested SELECT subqueries are all handled with proper indentation.
- Is the formatted SQL safe to run?
- The formatter only adjusts whitespace, line breaks, and keyword casing — it does not alter query logic. Always review the output before running it in production.
- Are SQL comments preserved?
- Yes. Both line comments (--) and block comments (/* */) are kept intact in the output.
- Why does keyword casing matter?
- Many teams enforce a consistent keyword casing style (e.g. uppercase keywords) in their coding standards. This tool lets you unify casing with a single click.
Found a bug or something not working as expected?
Report a bug →