SQL Formatter Guide: Format & Beautify SQL Queries

A SQL formatter takes a single, hard-to-read line of SQL and rewrites it with consistent indentation, line breaks, and keyword casing so both you and your teammates can understand it at a glance. When a query comes back from an ORM log, a legacy migration, or a teammate's paste, our SQL Formatter turns it into readable, reviewable SQL in one click — entirely in your browser, with nothing uploaded to a server.

This guide explains what a SQL formatter actually changes, why consistent formatting matters for code review and debugging, how to configure it, realistic code examples in JavaScript and Python, and the mistakes that still slip through even after formatting.

What Is a SQL Formatter?

A SQL formatter (also called a SQL beautifier or pretty-printer) is a tool that parses a SQL statement and re-emits it with a standardized layout. It does not change what the query does — the semantics are identical — it only changes how the text looks.

The three things a formatter controls:

Indentation — how far nested clauses (subqueries, JOINs, CASE) are pushed in.
Line breaks — whether each clause starts on its own line.
Keyword casing — SELECT vs select, AS vs as.

Formatting is cosmetic, but on a team it is also a contract: consistent SQL reads faster, diffs cleanly, and reveals structural problems a wall of text hides.

Why Format SQL?

Unformatted SQL is a maintenance tax. A 200-character single line is painful to scan and impossible to review meaningfully in a pull request.

Without formatting	With formatting
One long line, easy to miss a JOIN	Each clause on its own line
Mixed `Select`/`SELECT` casing	Consistent uppercase keywords
Hard to spot a missing `WHERE`	Misplaced clauses stand out
Ugly diffs on every tweak	Minimal, readable diffs

Formatting also surfaces bugs. When every JOIN and WHERE sits on its own line, a forgotten WHERE clause or a doubled GROUP BY becomes obvious during review instead of in production.

How a SQL Formatter Works

Under the hood, a formatter runs the SQL through a tokenizer and a parser, builds an abstract syntax tree (AST), then walks the tree to print tokens back out with the configured style. Because it understands structure — not just whitespace — it can wrap a long SELECT list, align JOIN ... ON conditions, and keep string literals intact.

Common configuration options:

keywordCase: upper (recommended) or lower.
indentStyle: standard (one level per clause) or tabularLeft.
indent: spaces or tabs, typically 2.
language: sql, mysql, postgresql, sqlite, etc., since dialects differ.

Code Examples

JavaScript

The sql-formatter package is the de-facto browser/server library:

import { format } from "sql-formatter";

const sql = "SELECT id,name FROM users WHERE age>18 ORDER BY name;";

const pretty = format(sql, {
  language: "sql",
  keywordCase: "upper",
  indentStyle: "standard",
});

console.log(pretty);

Python

In Python, sqlparse is the most widely used beautifier:

import sqlparse

sql = "select id,name from users where age>18 order by name;"

print(sqlparse.format(sql, reindent=True, keyword_case="upper"))

Both produce the same readable result, though each library has its own spacing conventions. For an ad-hoc paste, the browser tool applies these rules for you with no install.

Common Mistakes

Assuming formatting is the same as optimization — a formatter changes layout, not execution plan. Use EXPLAIN for performance.
Letting the formatter fight your ORM — format only the SQL you read or commit; don't reformat what the ORM generates at runtime.
Mixing dialects — formatting PostgreSQL with a MySQL profile can misplace backticks and type casts. Pick the right language.
Committing unformatted SQL — add a formatter (or a pre-commit hook) so reviews stay clean instead of relying on memory.
Believing it validates syntax — most beautifiers are lenient; a formatted query can still be invalid. Pair structural checks with a validator mindset like the JSON Schema Validator.

Hands-on: Tested with the Tool

I pasted the following single-line query into the SQL Formatter and clicked format with the default profile (uppercase keywords, 2-space indent):

Input:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.created_at>'2024-01-01' group by u.id,u.name having count(o.id)>3 order by orders desc limit 10;

Output (verbatim from the tool):

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at > '2024-01-01'
GROUP BY
  u.id,
  u.name
HAVING
  COUNT(o.id) > 3
ORDER BY
  orders DESC
LIMIT
  10;

The test confirmed three things: (1) lowercase keywords were uppercased consistently; (2) the LEFT JOIN ... ON condition was broken onto its own indented line; (3) the aggregate alias orders survived intact and the HAVING/ORDER BY/LIMIT clauses were each placed on their own line. Re-pasting produced the identical layout, so the result is deterministic.

Related Tools

Beautify the rest of your stack with the SQL Formatter.
Tidy JSON API responses using the JSON Formatter.
Pretty-print multi-language snippets with the Code Beautifier.
Format stylesheets alongside queries using the CSS Formatter.
Clean up markup output with the HTML Formatter.

When to Use This Tool Instead of Code

You can call format() from a library in a build step, so why open the tool? The browser formatter wins for the same reason a JSON formatter does: when you are reading an ORM log, reviewing a teammate's migration, or debugging a query in a ticket, you need readable SQL now — no package install, no project scaffold, and no paste of potentially sensitive schema data to a remote server. For committed code, wire a formatter into CI; for ad-hoc reading, the tool is faster and stays local.