SQL Formatter

Our SQL formatter supports Standard SQL, MySQL, PostgreSQL, Oracle, SQL Server, SQLite, and BigQuery with dialect-specific formatting rules and keyword handling.

Yes, the formatter handles stored procedures, user-defined functions, triggers, and complex procedural blocks with proper indentation for BEGIN/END, IF/ELSE, and LOOP constructs.

Yes, use the Obfuscate feature to replace sensitive table names, column names, and values with placeholder text while preserving the query structure for safe sharing.

The analyzer examines your SQL to identify statement types, tables referenced, complexity rating, keyword usage, and performance characteristics to help optimize your queries.

Yes, the formatter processes entire SQL scripts containing multiple statements, properly separating and formatting each SELECT, INSERT, UPDATE, DELETE, or DDL statement independently.

Formatting rules adapt to the dialect you select: MySQL/MariaDB, PostgreSQL, T-SQL (SQL Server), SQLite, and Oracle PL/SQL. The main differences are keyword sets (LIMIT vs TOP vs FETCH FIRST), identifier quoting (backticks vs double quotes vs brackets), and statement separators - the formatter preserves whatever your dialect requires.

The default uppercases reserved keywords (SELECT, WHERE, JOIN) and leaves identifiers as written - the convention in most SQL style guides, including the widely-cited one maintained by Simon Holywell. Comma-first vs comma-last placement and AND/OR alignment at line starts are the two options that most affect diff readability in code review.

No. Only whitespace and letter case of reserved words change - never literals, identifiers, comments, or the logical operator placement that short-circuit evaluation might depend on for performance hints. The formatted query must produce the same plan on the same engine; if it does not, that is a formatter bug, not a semantic choice.