SQL Formatter

Standard SQL (ANSI), PostgreSQL, MySQL, MariaDB, SQLite, BigQuery, Snowflake, Redshift, IBM DB2, and Microsoft T-SQL (SQL Server). Choosing the right dialect matters for non-portable keywords: PostgreSQL's `RETURNING`, BigQuery's `STRUCT` and `UNNEST`, T-SQL's `OUTPUT INSERTED.*`, and Snowflake's `QUALIFY` only get treated as keywords (and properly indented) if the formatter knows the dialect. If you pick the wrong one, the formatter still produces readable output, but vendor-specific clauses might land in awkward positions. When in doubt, pick the dialect of the database the query is going to run against.

No. The formatter only changes whitespace, line breaks, indentation, and keyword casing (e.g., `select` → `SELECT`). It does not rewrite predicates, reorder JOINs, simplify expressions, or change anything that affects the query plan or result set. You can format a production query, run both versions, and the database will return identical results and use an identical execution plan. The one detail to know: comments are preserved but their relative position can shift a line or two as surrounding code re-indents — never enough to change semantics.

Cleanly. CTEs (Common Table Expressions, the `WITH ... AS (...)` syntax) get each CTE on its own indented block, with the main query below — which is the format that's actually readable when you have 5+ chained CTEs. Stored procedure bodies (T-SQL `CREATE PROCEDURE`, PostgreSQL `CREATE FUNCTION` with `$$` delimiters, MySQL `DELIMITER //`) are formatted as one logical unit with the body indented inside. Window functions, subqueries, and CASE expressions all get nested indentation that makes the structure pop visually. For 500+ line procedures, the readability gain is enormous.

Honestly, it often isn't — DataGrip, DBeaver, and Azure Data Studio all have excellent built-in formatters tuned to a specific dialect. This tool is for the cases where you don't have an IDE handy: SQL pasted into a Slack message, a query in a Jira ticket, a snippet in a code-review browser tab, or a quick format inside a Google Doc you're collaborating on. It's also useful for teams that share SQL across many editors (some on VSCode without an extension, some on plain text editors) and want a consistent house style without configuring each editor. For your daily query-writing workflow inside an IDE, use the IDE's formatter; for everything else, paste it here.

Yes, here — the formatting runs entirely in your browser using JavaScript. Your query is never uploaded, never logged, and never seen by any server. Open DevTools → Network tab before pasting and you'll see zero outbound requests. This matters because production queries often embed business logic, customer IDs, table names that reveal architecture, or PII in WHERE clauses. Many online SQL formatters do call back to a server (which is convenient because they can lean on Java-based parsers like JSqlParser), but that means your query sits in their request logs for some retention period. Local formatting trades a slightly less feature-rich parser for guaranteed privacy.