SQL Formatter
Format, minify, and validate SQL across 20 real database dialects — with three layout styles, keyword casing, and fine-grained spacing control. Runs entirely in your browser.
Before Your First Format
- Pick the actual dialect your query runs against, not just "Standard SQL" by default — bracket identifiers, backtick-quoted names, and dialect-specific functions only parse correctly under the right one.
- Run Validate before formatting a query you didn't write yourself. A parenthesis mismatch or unclosed string is far easier to fix while you can still see exactly where it broke.
- Try Tabular layout on a query with many similarly-shaped conditions — it turns a long WHERE clause into a scannable column instead of a wall of indented lines.
- Match Keyword Case to your team's SQL style guide once, then leave it — consistent casing across a codebase matters more for readability than which convention was chosen.
Features
Twenty Dialects, Because "SQL" Isn't Actually One Language
Every database vendor implements the SQL standard with its own extensions, quoting rules, and reserved words, and those differences aren't cosmetic — they change what parses at all. SQL Server wraps identifiers in [square brackets]; MySQL and BigQuery use `backticks`; standard SQL and PostgreSQL use "double quotes". Paging works differently too: LIMIT in MySQL and Postgres, TOP in SQL Server, FETCH FIRST in Oracle and standard SQL. A formatter that only understands one generic grammar either fails outright on dialect-specific syntax or — worse — silently mangles it. This tool parses against the real grammar for whichever of the 20 supported dialects you select, from the everyday (MySQL, PostgreSQL, SQL Server, SQLite) to the analytics-focused (BigQuery, Snowflake, Redshift, Databricks-flavored Spark SQL) to the more specialized (Db2, Hive, Trino, ClickHouse, DuckDB) — a breadth most free online SQL formatters don't come close to matching.
The practical upshot is that copying a query straight from your actual database client usually just works, quoting and all, instead of needing manual cleanup first. If a query includes a dynamic value you built with a regular expression — extracting an ID from a larger string before dropping it into a WHERE ... IN (...) clause, say — the SQL side of that workflow is exactly what this tool is for; the pattern-matching side stays with a dedicated regex tool.
Three Layouts for Reading a Query Differently
Standard layout puts each clause keyword — SELECT, FROM, WHERE — on its own line with the relevant fields indented underneath, the shape most people picture when they hear "formatted SQL." Tabular layout is less common but genuinely useful once you've tried it: the keyword and the first value share a line, and every following line aligns to that same column, turning a query into a clean visual block instead of a staircase. Right-aligned tabular takes that further by right-justifying the keywords themselves, so every clause's last letter lines up in a single column — a dense style some teams standardize on specifically because it makes a long query's clause structure scannable at a glance, without reading a single word.
Format, Minify, or Validate — Three Different Jobs
Most online SQL tools do one thing: beautify. This one treats formatting, compressing, and checking as three separate, equally real needs. Format is for reading and reviewing — turning a dense query pasted from a log or an API response into something a person can actually follow. Minify is the inverse, useful surprisingly often: collapsing a query to one line to embed in a URL parameter, an environment variable, or a single log entry, while still respecting every quoting convention so a semicolon or comment marker inside a real string literal is never mistaken for query syntax. Validate does neither — it only confirms the query parses, surfacing the exact error and location if it doesn't, which is the fastest way to find a typo in a large script before spending time reviewing formatted output that was never going to be right.
The three actions also compose well together. Format a script to review it, fix whatever Validate flagged along the way, then Minify the final version if it's headed somewhere space-constrained — a webhook payload, a saved query string, or a value that eventually gets Base64-encoded for transport inside another system entirely.
The Small Style Choices That Add Up
Keyword case is the most visible style decision — SELECT versus select versus leaving it exactly as typed — and purely cosmetic; every SQL engine treats keywords case-insensitively regardless of which you pick. Dense Operators trims the space around =, >, and arithmetic operators for teams that prefer a tighter visual style. AND / OR at Line Start controls whether a multi-line WHERE clause reads with each condition's connector leading the line or trailing the one above it — a small choice that changes how naturally a long condition list scans top to bottom. None of these settings touch what the query actually does; they're entirely about how it reads on screen, which is exactly why they're safe to experiment with freely.
Semicolon placement is a smaller decision that matters more than it seems once a script has several statements back to back — a semicolon left hanging at the end of a long line is easy to miss when scanning for where one statement ends and the next begins, which is exactly the case Semicolon on Its Own Line exists to fix. Extra Spacing Between Statements solves a related but different problem: giving each statement in a multi-query script room to breathe, rather than having them run together with only a single blank line as the only visual separator.
A Slow-Query Log Is Usually the Trigger
Production logs almost always capture SQL as a single dense line, and a slow-query log or a support ticket with a pasted query is the single most common reason someone reaches for a formatter under time pressure. Formatted, a missing join condition or an accidental cross join is visible in seconds; dense, it can hide in plain sight for an hour. The same applies to a query generated by an ORM or a low-code tool — functionally correct, rarely written for a human, and worth reformatting before debugging rather than after.
Outside of firefighting, formatting earns its place earlier too: standardizing dialect and keyword case across a migration or schema file before a commit, then diffing the result against the previous version in the Text Diff Checker to confirm only formatting changed, not logic. And once a query is going somewhere other people will read — documentation, a code review, a JSON-wrapped API payload — consistent formatting means it reads the same way for everyone looking at it, regardless of who originally wrote it or where it came from.