SQL formatter
freeFormat SQL for 10 dialects — Postgres, MySQL, SQL Server, BigQuery, Snowflake, more.
Output will appear here.1→0 lines · 183→0 chars · 0 statements · / focus · ⌘⇧C copy · ⌘⇧D diff
Format SQL queries from any dialect — PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle (PL/SQL), BigQuery, Snowflake, Redshift, or generic ANSI. Configurable keyword case, indent, comma style, logical-operator placement, and line width. Multi-statement-aware. Runs entirely in your browser — pasted SQL never leaves the tab.
Common use cases
- Reading SQL from application logs. Paste the one-line query your ORM emitted into the logs. The formatter expands CTEs, joins, and subqueries into something you can actually skim. Case-insensitive — `select`, `SELECT`, and `Select` all parse the same.
- Normalising a migration before review. Drop a `.sql` file in to standardise indentation, comma style, and AND/OR placement to your team's convention. The diff view shows exactly what whitespace changed so reviewers don't lose time on layout.
- Sanity-checking dialect-specific syntax. Picked BigQuery? `STRUCT<>` types and `UNNEST()` format correctly. Picked SQL Server? `TOP N` and `CROSS APPLY` keep their right shape. Picking the wrong dialect surfaces a parse error rather than silently mangling.
- Cleaning up auto-generated query strings. Paste output from Prisma, ActiveRecord, SQLAlchemy, or a query builder. The single line of unindented SQL becomes properly indented, ready to drop into a Wiki, PR description, or Slack thread.
Frequently asked
Which SQL dialects are supported?
Standard SQL (ANSI), PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle (PL/SQL), BigQuery, Snowflake, and Amazon Redshift. The dialect picker also auto-detects when you drop a file in — `TOP N` → SQL Server, `RETURNING` → PostgreSQL, backticks → MySQL, etc.
Does my SQL leave the browser?
No. The formatter is the `sql-formatter` package compiled to JavaScript, running locally in your browser. There's no server roundtrip. Safe for proprietary schema, embedded literals (passwords, API keys you didn't strip), or anything you wouldn't paste into a public pastebin.
Will it change the meaning of my query?
No — only whitespace, indentation, and (optionally) keyword/identifier case. Identifiers and literals are preserved exactly. The Diff view shows exactly which lines moved or split, so you can confirm semantically nothing has shifted before pasting back.
What's the difference between Output and Diff view?
Output shows the formatted result. Diff shows your original input and the formatted output side-by-side with line-by-line markers — useful for confirming the formatter only re-indented (didn't drop comments, rename tokens, etc.) before you commit the change.
How does the leading-comma option work?
Toggles between `column1,` at the end of each line (trailing — Prettier-style) and `, column2` at the start (leading — DBA-style). Affects only top-level commas in SELECT / GROUP BY / ORDER BY; commas inside `VALUES (...)` tuples or function calls stay where they are.
Why are AND / OR sometimes at the start of the next line?
That's the default — readability research suggests leading-AND lets you scan a WHERE clause vertically. Flip to trailing-AND in the Options menu if you prefer end-of-line. The setting persists across pages.
Are keyboard shortcuts available?
`/` focuses the input, `⌘⇧C` copies the output, `⌘⇧D` toggles the diff view. The dropdown menus are keyboard-navigable; the dialect picker remembers your last choice in localStorage.