SQL Formatter & Beautifier

A SQL formatter is a tool that parses a SQL statement and re-emits it with standard keyword casing, predictable indentation, and line breaks at clause boundaries so a query is readable, reviewable, and diffable. The query’s behavior never changes. Only its presentation does.

Database engineers, analytics teams, and backend developers use a SQL formatter every time a one-line query pulled from an ORM log, a BI tool, or a stack trace needs to be inspected. A 600-character SELECT with nested subqueries is unreviewable until it is broken across lines and indented by clause. Formatting also surfaces logic problems such as a stray AND in a WHERE clause or a GROUP BY that does not match the projected columns.

Why use a SQL formatter?

• Make long queries reviewable. Auto-generated SQL from ORMs like Hibernate, Prisma, or SQLAlchemy arrives as a single line of hundreds of characters. Formatting breaks it across clauses so the join graph, predicates, and projections are legible at a glance.
• Standardize style across the team. Uppercase keywords, lowercase identifiers, and predictable indentation make every query in a migration directory look the same, which speeds up pull request reviews and shrinks diffs to actual logic changes.
• Catch logic errors during formatting. A formatter that parses the query (rather than tokenizing it) refuses to format malformed SQL. An unbalanced parenthesis or a missing FROM shows up immediately instead of at runtime.
• Convert dialect-specific syntax. Pasting MySQL backticks into a PostgreSQL session breaks. A formatter that supports dialect selection normalizes quoting and reserved-word handling for the target database.
• Bridge BI tools and source control. Queries lifted from Looker, Metabase, or Mode are flat strings. Formatting them turns those queries into versionable, review-friendly SQL files.

How to use the SQL Formatter

1. Paste your SQL into the Input panel. Any dialect parses, including PostgreSQL, MySQL, SQL Server, SQLite, BigQuery, Snowflake, and Redshift.
2. Click Format. Keywords are uppercased automatically.
3. Read the rewritten statement in the Output panel. Each major clause starts on its own line and joins are aligned under their parent table.
4. Click Copy to put the formatted SQL on your clipboard, then paste it into your migration file, BI tool, or pull request.

SQL formatting rules

The SQL formatter follows the conventions popularized by the sql-formatter  library and matched by the SQL style guides at GitLab, Mozilla, and dbt.

Examples

A one-line query from an ORM log:

SELECT u.id, u.email, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at > '2025-01-01' AND u.deleted_at IS NULL GROUP BY u.id, u.email HAVING COUNT(o.id) > 5 ORDER BY order_count DESC LIMIT 100;

After formatting, every clause is on its own line and the join is aligned:

SELECT
  u.id,
  u.email,
  COUNT(o.id) AS order_count
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at > '2025-01-01'
  AND u.deleted_at IS NULL
GROUP BY
  u.id,
  u.email
HAVING
  COUNT(o.id) > 5
ORDER BY
  order_count DESC
LIMIT
  100;

SQL Formatter vs alternatives

Most teams reach for one of three options when SQL needs prettifying. Each has a place, and the right pick depends on whether the SQL lives in a file, in an IDE, or in a chat thread.

For ad-hoc queries pulled from a Slack thread or a stack trace, an in-browser SQL formatter is the fastest path. For project-wide consistency, wire prettier or sqlfluff into pre-commit hooks.

Common use cases

• Backend developers unpacking auto-generated SQL from Prisma, SQLAlchemy, or Hibernate logs to debug a slow query.
• Data engineers standardizing dbt models and migration files before opening a pull request.
• Analytics teams converting BI-tool SQL from Looker, Metabase, or Mode into reviewable .sql files for version control.
• DBAs auditing stored procedures and view definitions exported from a database.
• Interview candidates formatting take-home SQL exercises before submission.

Frequently asked questions

Should SQL keywords be uppercase or lowercase?

There is no universal rule, but UPPERCASE keywords with lowercase identifiers is the most common convention and the default in this SQL formatter. UPPERCASE keywords visually separate language tokens from table and column names, which makes complex queries easier to scan. Lowercase-only styles exist (notably dbt’s default) and are equally valid as long as the team picks one and sticks to it.

Does this SQL formatter execute the query?

No. The formatter parses the SQL syntactically and rewrites it. It does not connect to any database, run the statement, or evaluate the result. The query and any embedded values stay in your browser and never reach a server.

Which SQL dialects are supported?

The parser handles standard SQL plus dialect-specific syntax for PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), SQLite, Oracle PL/SQL, BigQuery, Snowflake, Redshift, Db2, and Spark SQL. Dialect-specific features like PostgreSQL’s ILIKE or BigQuery’s array literals are preserved verbatim.

Can it format DDL statements like CREATE TABLE?

Yes. CREATE TABLE, ALTER TABLE, CREATE INDEX, and CREATE VIEW statements are supported. Column definitions are aligned and constraints are placed on their own indented lines for readability.

How is SQL formatting different from SQL linting?

A formatter rewrites the statement to a canonical style. A linter (such as sqlfluff or sqlcheck) inspects the SQL for style violations, anti-patterns, and risky constructs without rewriting it. Most teams use both: a formatter for style, a linter for substance.

Will the formatter break my parameterized query?

Placeholder tokens like ?, $1, :name, and @var are preserved exactly as they appear. The formatter treats them as opaque literals so a query you copied from a logging library still binds the same way after formatting.

What about comments inside the query?

Both -- line comments and /* */ block comments are preserved in their original position. The formatter avoids reflowing comments to keep their meaning anchored to the right clause or column.

Can I format a query with CTEs?

Yes. Common table expressions defined with WITH are formatted with each CTE on its own indented block. Recursive CTEs and multi-CTE chains keep their structure, with commas placed at the end of each CTE definition.

Related tools

• YAML Formatter - clean up YAML manifests, workflow files, and Helm values.
• Markdown Formatter - normalize headings, lists, and code blocks across Markdown documents.
• TypeScript Formatter - apply Prettier defaults to TypeScript source files.
• SQL Minifier - collapse a formatted SQL statement back to a single line for embedding.