Skip to content

Tools/SQL Formatter

SQL Formatter

Pretty-print SQL for PostgreSQL, MySQL, SQLite, MariaDB, and T-SQL. Nothing is uploaded.

Loading tool…

How to use SQL Formatter

  1. 1. Paste a query. Drop in a one-line query, an ORM dump, or a snippet from a slow-query log.
  2. 2. Pick the dialect. PostgreSQL, MySQL, SQLite, MariaDB, T-SQL, or generic SQL changes how some functions and identifiers format.
  3. 3. Tune style. Set tab width and keyword case so the result matches your repository conventions.
  4. 4. Copy back to the editor. Formatted SQL is easier to review in pull requests and to paste into EXPLAIN tools.

About this tool

SQL is written more often than it is formatted. ORMs emit a single line. Query logs collapse whitespace. A beautifier does not optimize a plan; it only makes the statement readable so you can see joins, filters, and grouping. PureDevKit uses a client-side SQL formatter with dialect plugins, so production queries you paste for cleanup never leave the machine.

Why dialect matters

PostgreSQL, MySQL, and SQL Server disagree on quoting, pagination, JSON operators, and function names. `ILIKE`, `RETURNING`, and `::jsonb` are Postgres. backticks are MySQL identifiers. `[brackets]` are T-SQL. A generic formatter still helps, but picking the right dialect preserves those tokens instead of wrapping them oddly. SQLite is a third family: it is closer to the SQL standard in some places and very permissive in others (dynamic types, `INSERT OR REPLACE`).

Formatting is not validation

If a statement formats, it is not necessarily valid. The formatter understands enough grammar to place clauses; it will not connect to your database, resolve objects, or type-check expressions. For real validation, run `EXPLAIN` against a snapshot or use CI with a parser that targets your engine. Treat errors from the formatter as “this text confused the pretty-printer,” not as a full SQL linter.

Style and reviews

Teams that format SQL in pull requests review intent instead of wrapping. Uppercase keywords are a traditional convention; many modern style guides keep lowercase keywords and uppercase types. Pick one and set the toggle to match. Indentation width should match the surrounding codebase (2 in JS-heavy shops, 4 in Python). Do not mix tabs and spaces inside a query string if your linter is strict.

Secrets in queries

Slow-query logs sometimes inline emails, tokens, or session IDs in literals. Paste with care, even into a local tool, and redact before sharing screenshots. Parameterize in application code (`$1`, `?`) so literals never land in logs in the first place.

Code examples

Postgres EXPLAIN

EXPLAIN ANALYZE
SELECT u.email, COUNT(*)
FROM users u
JOIN orders o ON o.user_id = u.id
GROUP BY u.email;

Node

import { format } from "sql-formatter";
format(sql, { language: "postgresql" });

Parameterized

SELECT * FROM users WHERE email = $1; -- Postgres
SELECT * FROM users WHERE email = ?;  -- MySQL / SQLite

Frequently asked questions

Related tools

All tools