SQL Formatter

What Does a SQL Formatter Do?

A SQL formatter takes compressed or unformatted SQL and adds consistent indentation, uppercase keywords, and logical line breaks — transforming a single-line wall of text into a readable, debuggable query. It parses your SQL into an Abstract Syntax Tree (AST) and rebuilds it using standardized formatting rules, without changing the query's logic, execution plan, or results.

How to Use the SQL Formatter

1. Paste your SQL. Copy your unformatted or minified query and paste it into the input panel.
2. Select your dialect. Choose Standard SQL, MySQL, PostgreSQL, or T-SQL so dialect-specific keywords are recognized and handled correctly.
3. Format. Click Format. The tool rebuilds the query with consistent indentation, uppercase keywords, and line breaks at logical points — after SELECT columns, before FROM, JOIN, WHERE, and GROUP BY clauses.
4. Copy the output. Copy the formatted SQL and use it in your editor, documentation, code review, or share it with a colleague.

Who Is This For?

• Analysts writing ad-hoc queries in data tools — when you export a query from a BI tool or ORM, it often comes back as a single unreadable line; formatting it makes debugging straightforward.
• Developers reviewing query performance who need to read complex JOIN chains and subqueries clearly before analyzing execution plans or adding indexes.
• Anyone who receives minified SQL from a third-party tool — ORMs, query builders, and database GUIs often output single-line SQL; this formatter makes it immediately readable.

Key Benefits

• 100% private — formatting runs in your browser; your queries and schema are never transmitted to or stored on any server. Safe for production database queries and internal schema.
• Completely free — no subscription, no sign-up, no paywall.
• No account required — paste and format immediately.
• Multi-dialect support — Standard SQL, MySQL/MariaDB, PostgreSQL, and T-SQL; dialect-specific keywords are recognized correctly for each engine.

Common SQL Formatter Mistakes

• Reformatting SQL with database-specific syntax for the wrong dialect: MySQL and PostgreSQL use different quoting conventions and have different reserved words. Always select the correct dialect before formatting — otherwise the formatter may misidentify identifiers as keywords or vice versa.
• Losing intentional inline subqueries: Some developers write subqueries inline for readability. Auto-formatting may expand them to multi-line, changing the visual grouping that the original author intended. Review the output before committing formatted SQL to version control.
• Breaking stored procedure formatting: Stored procedures contain control flow (IF, WHILE, BEGIN/END) that formatters handle inconsistently across dialects. Always verify that procedure logic is intact after formatting.
• Not preserving string literals containing SQL keywords: A string value like 'SELECT * FROM users' stored in a column should not have its contents reformatted. A well-written formatter respects string literal boundaries, but always visually confirm after formatting.

After formatting, use the JSON formatter to validate any JSON fields embedded in your SQL results. For comparing two versions of a query before and after refactoring, the diff checker highlights exactly what changed.

Further reading: ISO/IEC 9075 — SQL Standard (ISO)

Worked Example: Formatting an ORM-Generated Query

An ORM outputs the following single-line debug SQL:

SELECT u.id, u.email, o.total, o.created_at FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.total > 100 AND o.created_at > '2024-01-01' ORDER BY o.created_at DESC LIMIT 50;

After pasting and clicking Format (PostgreSQL dialect):

SELECT
  u.id,
  u.email,
  o.total,
  o.created_at
FROM
  users u
  INNER JOIN orders o ON u.id = o.user_id
WHERE
  o.total > 100
  AND o.created_at > '2024-01-01'
ORDER BY
  o.created_at DESC
LIMIT
  50;

Each clause is now on its own line. The INNER JOIN condition is immediately visible — making it trivial to spot a missing index on o.user_id that would cause a full table scan.

How This Formatter Compares

Last updated: April 2026. Supports Standard SQL, MySQL/MariaDB, PostgreSQL, and T-SQL.

Common Use Cases

A data engineer receives a query from an ORM debug log as a 400-character single-line string — pasting it here reveals a missing index opportunity in the JOIN condition that was invisible before. A backend developer copies a complex stored procedure from a SQL Server dump and formats it to review logic before porting it to PostgreSQL. An analyst working in a BI tool that outputs minified SQL formats the query to understand what joins and filters the tool built automatically before modifying it.

Frequently Asked Questions