Formatting SQL for reviews

Published: 2026-09-05

Why consistent SQL layout helps pull requests, how dialect-aware beautify and minify differ, and a privacy-friendly browser workflow for reviewing queries and CREATE TABLE scripts.

SQL in a pull request is often harder to review than application code: long one-liners from ORMs, hand-edited migrations with mixed indentation, and dialect-specific quirks (LIMIT vs TOP, backticks vs double quotes) all fight the eye. Formatting does not prove the query is correct—but it makes structure, joins, and predicates visible so reviewers can focus on behavior instead of hunting for a missing comma.

Online “paste SQL” formatters frequently upload query text to a server. Production queries can contain table names, filter values, or comments that hint at schema and data. Prefer a local formatter that never leaves the tab. LocalTools’ SQL Formatter Studio beautifies or minifies SQL in the browser with the same local-only model as other developer tools on the site.

What “formatted for review” means

A review-friendly SQL layout usually:

Puts major clauses (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) on clear lines or indented blocks.
Aligns lists of columns, join conditions, and AND / OR predicates so differences stand out in a text diff.
Uses consistent spacing around operators and commas.
Keeps comments readable instead of jammed into a single line (when you beautify; minify is the opposite job).

Formatting is a presentation step. It should preserve the SQL’s meaning for the chosen dialect. It does not rewrite logic, add indexes, or validate that tables exist.

Dialect matters

“SQL” is a family of related languages. Keyword casing and core clauses overlap, but identifiers, types, and extensions diverge. The studio supports four common targets:

Dialect	Typical home	Review gotchas
PostgreSQL	Postgres, many cloud DBs	`"QuotedIdentifiers"`, `RETURNING`, distinct types and functions
MySQL	MySQL / MariaDB	Backtick identifiers, `LIMIT`/`OFFSET`, engine-specific DDL
SQLite	Embedded / local apps	Flexible typing, fewer ALTER options, simpler dialect surface
T-SQL	SQL Server	`TOP`, brackets `[identifiers]`, procedural batches

Pick the dialect that matches the database that will run the statement. Formatting with the wrong dialect can still “pretty-print,” but keyword highlighting, reserved-word handling, and edge-case layout may not match what your team ships. Schema builder type suggestions also follow the selected dialect.

Beautify vs minify

Mode	Goal	Use when…
Beautify	Readable, indented multi-line SQL	PR review, debugging, documenting a query in a ticket
Minify	Compact text: strip comments and extra whitespace	Embedding SQL in a string literal, reducing noise in a log line, or packing a one-liner for a tool that expects a single line

Beautify for humans; minify for machines (or constrained paste). Do not minify a migration just before review—you lose the layout reviewers need. If you must ship a compact string in app code, keep a beautified copy in the PR description or a .sql fixture for humans.

Minifying is not the same as optimizing the query plan. It only changes whitespace and comments (per the formatter), not joins or indexes. For a similar “strip insignificant whitespace” idea in another format, see minifying JSON safely.

A practical PR workflow

Paste the query as it appears in the branch (or export it from the ORM / migration file).
Select the real dialect, then Beautify.
Scan structure first — FROM/JOIN order, WHERE predicates, GROUP BY vs SELECT lists — before arguing about style.
Diff against the previous version with a local diff if the change is a rewrite; format both sides the same way first so the diff is about SQL, not indentation churn.
Scrub secrets before pasting into chat or screenshots (customer IDs in WHERE clauses, connection strings in comments). Treat exported SQL like any other shareable artifact.
Copy the highlighted output back into the PR or ticket when the layout helps the discussion.

For greenfield tables, the studio’s Schema Builder can generate a dialect-aware CREATE TABLE from column names, types, and constraints (NOT NULL, primary key, unique, defaults). That is handy for draft DDL in reviews; still verify types and constraints against your migration policy before merging.

What formatting will not catch

Logic bugs — Wrong join keys, inverted predicates, and missing WHERE filters still look “pretty.”
Injection risk — Beautifying a string that concatenates user input does not make it safe; use parameterized queries in application code.
Performance — Indentation does not replace EXPLAIN / query plans.
Exact byte stability — Two formatters (or two dialect settings) can produce different but equivalent layouts. Prefer one agreed tool in CI or docs so diffs stay small.
Huge scripts — Very large dumps can stress the browser tab; format the statement under review, not an entire database dump, when possible.

Try it locally

Open SQL Formatter Studio:

In SQL Editor, paste SQL, choose PostgreSQL, MySQL, SQLite, or T-SQL.
Click Beautify for review layout or Minify for a compact string.
Optionally use Schema Builder to design columns and copy a generated CREATE TABLE.
Copy from the highlighted output panel.

Formatting, minification, and DDL generation run in your browser; query text is not uploaded to LocalTools.