Data tool

SQL Formatter

Paste ugly SQL. Get clean, readable, dialect-aware SQL. Fourteen engines supported, every knob you would expect from your IDE, and the whole thing runs in your browser — nothing you paste leaves the tab.

ShareX LinkedIn Email

Formatting runs locally in your browser. Nothing is sent to a server.

Dialect

Keyword case

Indent

Comma style

Lines betweenbetween queriesWrap widthchars

Input

278 chars1 lines1 query

Output

SELECT
  u.id,
  u.name,
  u.email,
  count(o.id) AS order_count,
  sum(o.total) AS revenue
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at > '2024-01-01'
  AND u.status = 'active'
GROUP BY
  u.id,
  u.name,
  u.email
HAVING
  count(o.id) > 5
ORDER BY
  revenue DESC
LIMIT
  100;

308 chars22 lines+30 chars vs input

Why formatting SQL is worth the effort

Almost every SQL bug I have chased in production started with a wall-of-text query nobody wanted to read carefully. Formatting is not cosmetic. When the SELECT list, JOIN structure, WHERE clauses, GROUP BY and ORDER BY all sit at predictable positions, a reviewer can spot a missing filter, a wrong join key, or a repeated column in seconds. On an unformatted one-liner, the same review takes minutes and gets skipped.

The other reason: diffs. Formatted SQL produces small, meaningful diffs when you add a column. Unformatted SQL produces one giant diff of the whole line every time, and the reviewer cannot see what actually changed.

Dialects worth knowing

PostgreSQL. The default. Double-quoted identifiers, generous type system, modern JSON and array operators.
MySQL / MariaDB. Backticked identifiers, slightly different reserved words, different string-escaping rules.
SQLite. Simpler grammar, more permissive parsing. Both double-quotes and backticks are accepted for identifiers.
SQL Server (T-SQL). Square-bracket identifiers, TOP instead of LIMIT, its own datetime functions.
BigQuery / Snowflake / Redshift. Cloud warehouses with backtick or double-quote identifiers depending on the engine, plus warehouse-specific functions (BigQuery's STRUCT, Snowflake's VARIANT).
Standard SQL. Falls back on ANSI SQL rules. Safe pick when you do not know or care about the target engine.

How this tool handles your data

The formatter runs inside your browser via the open-source sql-formatter library.
The SQL you paste never leaves the tab. No network request, no storage, no logging.
The site uses Google Analytics for page-view counts only. It does not observe the formatter's input or output.
Open DevTools → Network before you paste. You will not see a request go out.

Frequently asked

Which SQL dialect should I pick?: Pick the engine your query will actually run against. The differences matter mostly around identifier quoting (backticks in MySQL, double quotes in Postgres), reserved words, and function names. If you are not sure, "Standard SQL (generic)" is a safe fallback that follows the ANSI SQL rules.
Is my SQL sent to any server?: No. The formatter is a pure JavaScript library that runs inside your browser tab. Nothing is sent to a server, nothing is stored, nothing is logged. Open your browser DevTools → Network before you paste, then paste. You will not see a request go out.
What is the difference between trailing and leading commas?: Trailing places the comma at the end of each column line — the default and what most style guides recommend. Leading puts the comma at the start of the next line, which makes it easier to spot missing commas and produces cleaner diffs when you add or remove columns. Some SQL Server teams prefer leading commas heavily.
Why does the formatter change my keyword casing?: Because consistent casing makes SQL easier to read at a glance. UPPER is the traditional style and the default. If your team uses lower or if you are working inside code where mixed case is the convention, pick lower or preserve.
Can this format machine-generated SQL from ORMs?: Yes. It is one of the most common uses. Paste in whatever comes out of Sequelize, Prisma, Hibernate, Django, ActiveRecord, or a raw log line — the formatter parses it and gives you back something a human can read.
Does it handle CTEs, window functions, and JSON operators?: Yes. Common Table Expressions (WITH ... AS), window functions (OVER (...)) and modern JSON operators (Postgres ->, ->>, @>) all format correctly. If you spot something that trips it up, tell me — the underlying parser is actively maintained and I can push fixes upstream.
What is the wrap width option for?: The formatter tries to keep expressions inside a single line under that character count. Above it, expressions get wrapped and indented. Set it lower if you want more aggressive wrapping (tight column layouts); higher if you want fewer line breaks. Zero disables width-based wrapping entirely.
Does this replace my IDE's formatter?: It replicates most of what pgAdmin, DBeaver, DataGrip, and VS Code SQL plugins do — with the advantage of working on any machine, in any browser, without installing anything. Handy when you are pair-programming, reviewing SQL over Slack, or working on a locked-down machine where installing a formatter is not an option.

ShareX LinkedIn Email

More tools

All tools →

Password Generator

Open →

Random passwords, easy-to-read variants, pronounceable passwords, or diceware passphrases. Runs entirely in your browser.

Password Strength Checker

Open →

Paste any password and see how strong it really is. Entropy, estimated crack time, and specific suggestions. Never leaves your browser.

UUID Generator

Open →

Generate UUIDs (v1, v3, v4, v5, v7) in any format. Batch up to 1000, download as TXT/CSV/JSON, or grab SQL-ready INSERT rows. Public API included.

API Key Generator

Open →

Cryptographically secure API keys with prefixes, minimum-character rules, 11 output formats (env, YAML, JS, Python, .NET, Java, PHP, Bash, more), QR transfer, and a paste-in validator.

Timestamp Converter

Open →

Convert between Unix timestamps and human dates in any timezone. Seconds, milliseconds, ISO 8601, RFC 2822. Batch mode and live current-time.

SELECT u.id, u.name, u.email, count(o.id) AS order_count, sum(o.total) AS revenue FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at > '2024-01-01' AND u.status = 'active' GROUP BY u.id, u.name, u.email HAVING count(o.id) > 5 ORDER BY revenue DESC LIMIT 100;

Why formatting SQL is worth the effort

Dialects worth knowing

PostgreSQL. The default. Double-quoted identifiers, generous type system, modern JSON and array operators.

MySQL / MariaDB. Backticked identifiers, slightly different reserved words, different string-escaping rules.

SQLite. Simpler grammar, more permissive parsing. Both double-quotes and backticks are accepted for identifiers.

SQL Server (T-SQL). Square-bracket identifiers, TOP instead of LIMIT, its own datetime functions.

BigQuery / Snowflake / Redshift. Cloud warehouses with backtick or double-quote identifiers depending on the engine, plus warehouse-specific functions (BigQuery's STRUCT, Snowflake's VARIANT).

Standard SQL. Falls back on ANSI SQL rules. Safe pick when you do not know or care about the target engine.

How this tool handles your data

The formatter runs inside your browser via the open-source sql-formatter library.

The SQL you paste never leaves the tab. No network request, no storage, no logging.

The site uses Google Analytics for page-view counts only. It does not observe the formatter's input or output.

Open DevTools → Network before you paste. You will not see a request go out.

Frequently asked

Which SQL dialect should I pick?

Pick the engine your query will actually run against. The differences matter mostly around identifier quoting (backticks in MySQL, double quotes in Postgres), reserved words, and function names. If you are not sure, "Standard SQL (generic)" is a safe fallback that follows the ANSI SQL rules.

Is my SQL sent to any server?

No. The formatter is a pure JavaScript library that runs inside your browser tab. Nothing is sent to a server, nothing is stored, nothing is logged. Open your browser DevTools → Network before you paste, then paste. You will not see a request go out.

What is the difference between trailing and leading commas?

Trailing places the comma at the end of each column line — the default and what most style guides recommend. Leading puts the comma at the start of the next line, which makes it easier to spot missing commas and produces cleaner diffs when you add or remove columns. Some SQL Server teams prefer leading commas heavily.

Why does the formatter change my keyword casing?

Because consistent casing makes SQL easier to read at a glance. UPPER is the traditional style and the default. If your team uses lower or if you are working inside code where mixed case is the convention, pick lower or preserve.

Can this format machine-generated SQL from ORMs?

Yes. It is one of the most common uses. Paste in whatever comes out of Sequelize, Prisma, Hibernate, Django, ActiveRecord, or a raw log line — the formatter parses it and gives you back something a human can read.

Does it handle CTEs, window functions, and JSON operators?

Yes. Common Table Expressions (WITH ... AS), window functions (OVER (...)) and modern JSON operators (Postgres ->, ->>, @>) all format correctly. If you spot something that trips it up, tell me — the underlying parser is actively maintained and I can push fixes upstream.

What is the wrap width option for?

The formatter tries to keep expressions inside a single line under that character count. Above it, expressions get wrapped and indented. Set it lower if you want more aggressive wrapping (tight column layouts); higher if you want fewer line breaks. Zero disables width-based wrapping entirely.

Does this replace my IDE's formatter?

It replicates most of what pgAdmin, DBeaver, DataGrip, and VS Code SQL plugins do — with the advantage of working on any machine, in any browser, without installing anything. Handy when you are pair-programming, reviewing SQL over Slack, or working on a locked-down machine where installing a formatter is not an option.