SQL Formatter: Beautify SQL for Postgres, MySQL and SQL Server

A SQL formatter takes a query and rewrites its layout — indentation, line breaks, keyword casing, spacing around commas and parentheses — without changing what the query does. The single unbroken line your ORM logged and a version of it with every clause on its own line return the exact same rows from the exact same tables. Only the presentation changed.

Say this directly, because search results hedge on it constantly: a SQL formatter and a SQL beautifierare the same tool. “Beautifier” is just the older, slightly more casual name for the pretty-print direction of the same job — nobody is offering a fundamentally different feature under that label.

The reason this matters more for SQL than for most text is that SQL is read far more often than it's written. A query goes into a migration file, a pull request, a slow-query log, or a code review, and every one of those contexts is a reading context. A twelve-join query collapsed onto one line is genuinely hard to verify — which table does that WHERE clause actually filter, and which JOIN does that ON condition belong to? Laid out with one clause per line and subqueries indented under the clause that owns them, the same query becomes something a reviewer can actually check in a few seconds instead of retyping it by hand to understand it. Consistent formatting across a codebase also means a diff shows the logic change a teammate made — not a wall of whitespace noise because their editor auto-formats differently from yours.

GenKitLab's SQL Formatter — an online SQL formatter and SQL query formatter in one, whichever term you searched — does this by tokenizing the query first — splitting it into keywords, identifiers, string literals, comments, and punctuation — rather than doing find-and-replace on whitespace. That distinction is what keeps a -- inside a string literal from being mistaken for a comment, and what keeps the word selectused as a quoted column name from getting uppercased along with the real keyword. If all you need is to format SQL online in one paste with no download, that's the whole workflow: paste, pick a SQL pretty print style, copy the result.

Two terms get conflated constantly, and they're opposites: formatting (or beautifying) adds whitespace for readability; minifyingremoves it, collapsing a query to one line and stripping comments for the smallest possible payload — useful when a query template gets embedded in application code or a config value. If you want the second operation, GenKitLab's SQL Minifier is the dedicated tool for that direction; a formatter is not going to compact your query, and a minifier is not going to make it readable.

The second conflation is assuming all SQL is one dialect. It isn't, and the differences that actually change how a query gets formatted come down to two things: how each database quotes an identifier that needs quoting, and how it marks a bound parameter — which is exactly why a MySQL formatter and a T-SQL formatter can't just be the same tool with a different label slapped on.

A formatter that only recognizes one of these three will mangle the other two — it'll try to reinterpret a bracketed T-SQL identifier as an array literal, or choke on a MySQL backtick it doesn't expect. GenKitLab's formatter tokenizes all three quoting styles and all four common parameter styles ($1, ?, :name, and @name) regardless of which dialect you select in the editor — the dialect setting changes the hint shown in the UI, not what gets accepted, so a query copied from a different database still formats correctly instead of failing outright.

The last conflation is assuming there's one correct keyword-casing standard. There isn't — SQL keywords are case-insensitive to every engine, so SELECT, select, and SeLeCt all execute identically. Uppercase is the older, more widespread convention and makes the shape of a long query easy to scan against its identifiers. Lowercase has become increasingly common in codebases where SQL sits inline with application code written in a lowercase-keyword language. Neither is objectively right; the only actual rule is to pick one and enforce it consistently across a team, which is exactly what a keyword-case setting on a formatter is for.

The job changes slightly depending on where you sit in a stack, but the underlying need — readable SQL, fast — is the same one:

• Backend & API developers— paste the one-line query an ORM logged, or a query copied from a slow-query log, and get it back readable enough to actually review before deciding whether it needs an index or a rewrite.
• Database administrators & data engineers— run a migration file through a formatter before it goes into a pull request, so every statement in a repository follows the same keyword casing and indent width no matter who originally wrote it.
• Code reviewers— normalize two queries to the same style before diffing them, so the diff shows the actual logic change instead of whitespace noise introduced by a different editor's auto-format.
• Data analysts— untangle a sprawling, auto-generated query pulled out of a BI tool or notebook, with CTEs, subqueries, and joins indented consistently, before handing it to a teammate.
• QA engineers— format both an expected and an actual SQL string identically before comparing them in a test assertion, so an assertion failure reflects a real difference in the query rather than a difference in spacing.

The same multi-join query, run through the formatter three times with a different dialect selected each time. Watch what changes — identifier quoting and parameter placeholders — and what doesn't: clause layout, keyword casing, and every literal value.

MySQL — backticks, ? parameters

select o.id, c.name, sum(o.total) as revenue from `orders` o join `customers` c on c.id = o.customer_id where o.status = ? and o.created_at > ? group by o.id, c.name order by revenue desc limit 25;

SELECT
  o.id,
  c.name,
  sum(o.total) AS revenue
FROM
  `orders` o
JOIN `customers` c ON c.id = o.customer_id
WHERE
  o.status = ?
  AND o.created_at > ?
GROUP BY
  o.id,
  c.name
ORDER BY
  revenue DESC
LIMIT 25;

PostgreSQL — double-quoted identifiers, $1 parameters

select o.id, c.name, sum(o.total) as revenue from "orders" o join "customers" c on c.id = o.customer_id where o.status = $1 and o.created_at > $2 group by o.id, c.name order by revenue desc limit 25;

SELECT
  o.id,
  c.name,
  sum(o.total) AS revenue
FROM
  "orders" o
JOIN "customers" c ON c.id = o.customer_id
WHERE
  o.status = $1
  AND o.created_at > $2
GROUP BY
  o.id,
  c.name
ORDER BY
  revenue DESC
LIMIT 25;

SQL Server — bracketed identifiers, @named parameters

select o.id, c.name, sum(o.total) as revenue from [orders] o join [customers] c on c.id = o.customer_id where o.status = @status and o.created_at > @since group by o.id, c.name order by revenue desc;

SELECT
  o.id,
  c.name,
  sum(o.total) AS revenue
FROM
  [orders] o
JOIN [customers] c ON c.id = o.customer_id
WHERE
  o.status = @status
  AND o.created_at > @since
GROUP BY
  o.id,
  c.name
ORDER BY
  revenue DESC;

Notice what stayed inline in all three: sum(o.total)is a function call, not a subquery, so it isn't exploded across lines — the formatter decides per parenthesis by looking at what's inside it, and a plain function call reads worse broken up than left alone. The join condition also stays on the same line as its JOIN keyword, which is what keeps a query with several joins scannable instead of scattering related information across separate lines.

There's no single official SQL style standard the way Prettier enforces one style for JavaScript. What exists instead is a set of conventions that most teams converge on independently, because each one solves a specific, recurring readability problem:

One convention genuinely splits opinion: leading commas (, name at the start of the next line) versus trailing commas (name,at the end of the current line). Leading commas make a missing comma easier to spot visually; trailing commas read more naturally left to right and match how most other languages format lists. GenKitLab's formatter uses trailing commas, in line with the more common convention — the point of a style guide isn't to pick the objectively correct option, since there rarely is one, but to apply the same option everywhere so reviewers stop noticing formatting at all.

A browser tab is the right tool for a query you just pulled out of a log or a Slack message. It's the wrong tool once formatting needs to run automatically — on every file in a repository, or on every commit.

Unlike JSON, most editors don't ship a built-in SQL formatter — VS Code has no native Format Document command for .sqlfiles the way it does for JSON. Getting the same result in an editor means installing a formatting extension (several exist in the VS Code Marketplace) and configuring it with the same keyword-case and indent-width choices you'd set here, so a file formatted in an editor and a query pasted into this tool come out looking the same.

For a repository-wide check, the property that matters is idempotence: running a formatter on its own output has to return identical text, byte for byte. That's what makes it safe to wire formatting into a pre-commit hook or a CI lint step — a hook that reformats a file non-deterministically on every run is worse than no hook at all, since it would generate a new diff every single commit. GenKitLab's formatter is built as a pure, dependency-free function under the hood for exactly this reason, though the page itself runs in the browser only — wiring the same engine into a script or a hook means calling it from your own tooling rather than this page directly.

Worth saying plainly, because it's a checkable difference rather than a marketing claim: GenKitLab's SQL Formatter carries no ads and no upsell CTAs. Open the page and there is a formatter on it — nothing pushing a trial, a paid IDE add-in, or a “Pro” tier. That's not the norm in this space.

The honest read: sqlformat.org is a genuinely solid, no-nonsense formatter, and there's no reason to avoid it. Red Gate's SQL Prettify and Devart's formatting tools are a different category of product entirely — the free formatter on those sites exists specifically to funnel traffic toward a paid SSMS or Visual Studio add-in, which is a legitimate business model, but it does mean the page you land on is built to sell something rather than to document how the formatter actually behaves.

Formatting is one piece of a SQL workflow. GenKitLab runs a full SQL tools category, all client-side, all free:

• SQL Minifier — collapse a query to one line and strip comments, without touching string literals or quoted identifiers.
• SQL Query Builder — build a parameterized SELECT, INSERT, UPDATE, or DELETE visually for Postgres, MySQL, or SQL Server.
• SQL Query Explainer — read a query clause by clause and see what it actually does, including the joins your WHERE clause quietly turned into inner joins.

And a few tools that pair well with database work generally: JSON Formatter & Validator for the JSON columns and API payloads that live next to your SQL, UUID Generator for seeding primary keys in bulk, and ENV Parser for the connection strings and credentials that configure the database this SQL runs against.