SQL Formatter — Pretty-Print and Beautify SQL Queries Online

🔒 Runs in your browser — nothing is sent to a server

SQL formatter that turns any messy or single-line SQL query into a clean, readable structure in one click. Pick your dialect — PostgreSQL, MySQL, T-SQL, Oracle, BigQuery, Snowflake and more — and the formatter rewrites the query with proper indentation, top-level keywords on their own lines and consistent casing. Everything runs 100% inside your browser; your queries never leave your device, nothing is uploaded or logged.

Two-pane view: input and output side by side
Copied!

When to use a SQL formatter online

You reach for a SQL formatter any time a query arrives unreadable: a one-liner copied from a slow-query log, an ORM-generated statement that ships everything on a single line, a migration script auto-generated by a framework, an analytical query pulled from a notebook cell, or an ad-hoc report you need to put into a code-review PR. Browser-local formatting matters when the query contains sensitive table or column names, internal report definitions, customer-segment filters or any SQL referencing schemas you would rather not paste into a remote SaaS formatter. The formatted output sits ready for the PR description, the runbook or the team Slack.

How SQL pretty-printing works under the hood

SQL pretty-printing is an AST-driven pipeline. The `sql-formatter` library tokenises the query with a dialect-aware lexer that knows each engine's keywords, operators and identifier quoting rules; the parser then groups tokens into clauses (SELECT, FROM, WHERE, JOIN), expressions, subqueries and CTEs. The renderer walks the resulting structure: top-level keywords land on their own line at column zero, comma-separated select lists indent under each keyword, subqueries and CTEs gain one extra indent level per nesting depth, and the configured keyword case is applied to every reserved word. Comments, string literals, quoted identifiers and parameter placeholders pass through untouched. The whole pipeline runs in your browser in milliseconds, even on multi-CTE analytical queries.

Examples

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.active = true group by u.id, u.name order by orders desc limit 25;
Output
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.active = TRUE
GROUP BY
  u.id,
  u.name
ORDER BY
  orders DESC
LIMIT
  25;
SQL formatter — single-line SELECT pretty-printed
Input
insert into tools (slug, name, role) values ('sql-formatter', 'sql formatter', 'pretty print sql for review');
Output
INSERT INTO
  tools (slug, name, role)
VALUES
  (
    'sql-formatter',
    'sql formatter',
    'pretty print sql for review'
  );
SQL beautifier — payload that names the tool itself

FAQ

How do I format a SQL query?

Paste the query into the input above, pick your dialect (PostgreSQL, MySQL, T-SQL, BigQuery, etc.) and click Format. The SQL formatter parses the source through the `sql-formatter` library, places every top-level keyword (SELECT, FROM, WHERE, JOIN) on its own line, indents subqueries and CTEs, normalises keyword casing and emits a clean, readable layout. Comments and string literals pass through verbatim.

What is SQL beautifying or pretty-printing?

SQL beautifying — also called pretty-printing — reformats compact SQL by inserting line breaks, indentation and consistent keyword casing so a human can read and review the query. The semantics are unchanged: the same tables, columns, predicates and join order, just laid out for visual scanning. Most SQL pretty printers default to two-space indentation with uppercase keywords.

Which SQL dialects does this formatter support?

Standard SQL (default), PostgreSQL, MySQL, MariaDB, SQLite, MS SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Db2 and Hive / Spark SQL. Picking the right dialect matters: each engine has its own keywords (`MERGE INTO`, `LATERAL`, `QUALIFY`), quoting rules (backticks, double quotes, brackets) and parameter syntax. The dropdown sits at the top of the options panel.

How does the SQL pretty printer handle CTEs and subqueries?

CTE blocks (`WITH name AS (…)`) get one extra level of indent so the chain reads top-to-bottom. Subqueries inside `IN (…)`, `EXISTS (…)`, `FROM (…)` and lateral joins are indented under the parent statement. JOIN clauses land on their own line with the `ON` predicate aligned underneath. The result is diff-friendly — small query edits produce small, readable diffs in code review.

Will the SQL formatter preserve quoted identifiers, comments and parameters?

Yes. Quoted identifiers — backticks (MySQL), double quotes (PostgreSQL), square brackets (T-SQL) — keep their case exactly as written because they are case-sensitive in their respective engines. Line comments (`--`) and block comments (`/* */`) stay at their source position. Parameter placeholders (`?`, `:name`, `$1`, `@param`) pass through untouched so the formatted query still binds against your driver.

How does keyword case work?

Three modes. Upper (default) emits keywords as `SELECT`, `FROM`, `JOIN` — the conventional layout for SQL style guides. Lower emits `select`, `from`, `join` — popular in modern Node and Python codebases. Preserve keeps whatever case the source used. Identifier case is a separate option and defaults to Preserve because table and column names are usually intentional.

How is the SQL formatter different from a SQL linter?

A SQL formatter rewrites the cosmetic layout — whitespace, line breaks, keyword case — without changing the query. A linter (sqlfluff, pglint) inspects the query for stylistic issues, anti-patterns or correctness problems and reports them. The two are complementary: format first to produce a canonical layout, then lint to catch anything the formatter cannot fix.

Is it safe to paste a query with production data into this online SQL formatter?

Yes — the SQL formatter runs entirely in your browser via the `sql-formatter` library bundled into the page. Your query and the formatted output stay on your machine; nothing is uploaded, logged or cached. Safe for queries containing sensitive table names, customer-facing schemas, internal admin reports and any SQL you would not want a remote SaaS formatter to retain.

Glossary

SQL (Structured Query Language)

SQL is the ANSI/ISO-standard language for relational databases — defining schemas, querying rows, modifying data and managing transactions. Every major database engine (PostgreSQL, MySQL, SQL Server, Oracle, BigQuery, Snowflake) implements its own dialect of SQL with extensions and quirks. A SQL formatter reformats any valid query without changing its semantics; the same rows return before and after.

SQL formatter

A SQL formatter is any tool or function that takes a SQL query and emits it with controlled indentation, line breaks and keyword casing. Library implementations (`sql-formatter`, `pgformatter`), editor plugins (DataGrip, DBeaver) and CLI tools (`sqlfluff fix`) all qualify. Browser-local SQL formatters have a privacy advantage: queries with sensitive table or column names never leave the developer machine.

SQL dialect

A SQL dialect is a specific engine's implementation of SQL — PostgreSQL, MySQL, T-SQL (MS SQL Server), PL/SQL (Oracle), BigQuery, Snowflake, Redshift and so on. Dialects share the SQL core but diverge on identifier quoting, parameter syntax, function names, window-function extensions and reserved words. A dialect-aware formatter respects each engine's keywords and quoting rules so the formatted query still parses on the target database.

Quoted identifier

A quoted identifier is a table or column name wrapped in delimiters to permit characters that would otherwise be reserved — spaces, mixed case, keywords. PostgreSQL uses double quotes (`"order"`), MySQL uses backticks (`` `order` ``), MS SQL Server uses square brackets (`[order]`). A correct SQL formatter never changes the case or strips the delimiters because doing so would change which database object the query references.

Related tools