MT
My Toolbox

Free Online SQL Formatter — Pretty Print SQL Queries Instantly

Paste messy SQL to format it with proper indentation, keyword casing, and dialect-aware syntax. Supports MySQL, PostgreSQL, T-SQL, PL/SQL, SQLite, BigQuery, and more.

SQL Input
Formatted SQL

Why Format SQL?

SQL queries often start simple but grow complex quickly — joining multiple tables, nesting subqueries, or chaining CTEs. Without consistent formatting, these queries become difficult to read, debug, and review in pull requests.

A good SQL formatter applies uniform indentation, aligns clauses (SELECT, FROM, WHERE, JOIN) on their own lines, and standardizes keyword casing. This makes the logical structure immediately visible: you can scan the FROM clause to understand data sources, review JOINs for correctness, and verify WHERE conditions at a glance.

Different SQL dialects have unique syntax. MySQL uses backticks for identifiers, PostgreSQL supports dollar-quoted strings, T-SQL has TOP and CROSS APPLY, and BigQuery uses STRUCT and ARRAY. A dialect-aware formatter respects these differences and produces valid, idiomatic output for your target database.

How to Use

  1. Paste your SQL query into the input area.
  2. Select your SQL dialect from the dropdown (Standard SQL, MySQL, PostgreSQL, etc.).
  3. Choose your preferred indentation (2, 4, or 8 spaces).
  4. Optionally select keyword casing (uppercase or preserve).
  5. The formatted output appears instantly. Click Copy to use it.

When You Need This

Reviewing queries in pull requests

Format messy one-liner queries before committing them so reviewers can easily understand the logic without manually reformatting in their head.

Debugging complex joins and subqueries

When a query returns unexpected results, proper formatting helps you isolate which JOIN condition or WHERE clause is incorrect by making the structure visible.

Documenting database queries

When writing wiki pages, runbooks, or API documentation that includes SQL examples, formatted queries are far more readable for your audience.

Migrating between SQL dialects

When moving queries from one database to another, formatting with the target dialect helps you spot syntax that needs to be translated.

Tips

1.

Choose the correct dialect

Selecting the right dialect ensures the formatter handles database-specific syntax correctly. A PostgreSQL query with :: casts or MySQL with backtick identifiers will format more accurately with the right dialect selected.

2.

Use uppercase keywords for scannability

Uppercase SQL keywords (SELECT, FROM, WHERE) create a visual anchor that separates reserved words from table and column names, making queries easier to scan quickly.

3.

Format before committing to version control

Consistent formatting means diffs only show logical changes, not whitespace noise. This makes code review faster and git blame more useful.

4.

Break long SELECT lists onto separate lines

When selecting many columns, one per line makes it easy to add, remove, or comment out individual columns without affecting adjacent lines.

Examples

Format a basic SELECT

Transforms a one-line query into a readable multi-line format.

Input

SELECT id, name, email FROM users WHERE active = 1 ORDER BY name ASC LIMIT 100;

Output

SELECT
  id,
  name,
  email
FROM
  users
WHERE
  active = 1
ORDER BY
  name ASC
LIMIT
  100;

Format a JOIN query

Aligns JOIN clauses and conditions for clarity.

Input

SELECT o.id, o.total, c.name FROM orders o INNER JOIN customers c ON c.id = o.customer_id WHERE o.status = 'shipped' AND o.total > 50;

Output

SELECT
  o.id,
  o.total,
  c.name
FROM
  orders o
  INNER JOIN customers c ON c.id = o.customer_id
WHERE
  o.status = 'shipped'
  AND o.total > 50;

Format a CTE

Indents Common Table Expressions for readability.

Input

WITH active_users AS (SELECT id, name FROM users WHERE active = 1) SELECT * FROM active_users ORDER BY name;

Output

WITH
  active_users AS (
    SELECT
      id,
      name
    FROM
      users
    WHERE
      active = 1
  )
SELECT
  *
FROM
  active_users
ORDER BY
  name;

Limitations

  • Formatting is best-effort for complex vendor-specific syntax (stored procedures, CTEs with lateral joins). Standard ANSI SQL formats best.
  • Does not validate SQL — it formats syntactically but will not catch errors like missing table names or wrong column references.
  • Cannot format multiple SQL dialects simultaneously. Pick one dialect per session.
  • Very long queries (10000+ lines) may take a few seconds to format due to parser complexity.

Features

  • Format SQL with configurable indentation (2, 4, or 8 spaces)
  • Uppercase or preserve keyword casing
  • Support for 8 SQL dialects: Standard SQL, MySQL, PostgreSQL, T-SQL, PL/SQL, SQLite, BigQuery, MariaDB
  • Handles complex queries: CTEs, subqueries, JOINs, CASE expressions, window functions
  • Instant output as you type
  • 100% client-side — your SQL queries never leave your browser

FAQ

Does formatting change the behavior of my SQL?

No. Formatting only changes whitespace and optionally keyword casing. The logical meaning and execution plan of your query remain identical.

Which SQL dialect should I choose?

Choose the dialect that matches your target database. If unsure, "Standard SQL" works for most ANSI-compliant queries. Use a specific dialect when your query uses database-specific syntax like MySQL backticks or PostgreSQL array operators.

Can this format stored procedures or DDL statements?

Yes. The formatter handles CREATE TABLE, ALTER statements, stored procedures, and other DDL/DML statements. Complex procedural blocks (IF/ELSE, loops) are also supported for dialects that use them (T-SQL, PL/SQL).

Does uppercase casing affect query performance?

No. SQL is case-insensitive for keywords in all major databases. Uppercase keywords are purely a readability convention and have no impact on execution.

Is my SQL sent to any server?

No. All formatting runs locally in your browser. Your queries are never transmitted over the network.

Content last reviewed: June 2026

Your Privacy

All SQL formatting happens entirely in your browser. No data is uploaded to any server. Your queries and database schema information never leave your device.

Tips & Related Workflows