Key takeaways
- 01Supports PostgreSQL, MySQL, SQLite, BigQuery, and standard SQL with dialect-aware keyword handling.
- 02Choose keyword case (UPPERCASE, lowercase, or preserve) and indentation (2 spaces, 4 spaces, or tabs).
- 03Runs entirely in your browser — queries with sensitive data never leave your device.
- 04The tool only reformats text; it does not execute queries or connect to any database.
Why Format SQL Before You Share It?
Unformatted SQL is genuinely hard to review. Long SELECT lists smashed onto one line, inconsistent indentation in subqueries, and mixed-case keywords all slow down code reviews and debugging. A properly formatted query makes JOIN conditions, WHERE clauses, and CTE structure immediately readable.
Formatting becomes even more important when sharing queries across a team with a style guide — UPPERCASE keywords, four-space indentation, one clause per line. Handytool's SQL formatter enforces that style consistently across everything you paste in, whether it's a two-line lookup or a 200-line analytical query with multiple CTEs and window functions.
How to Format a SQL Query
- 01
Paste your SQL
Paste any SQL statement into the input panel — SELECT, INSERT, UPDATE, DELETE, CREATE, or a full CTE chain. There's no size limit beyond your browser's available memory.
- 02
Select the dialect
Choose PostgreSQL, MySQL, SQLite, BigQuery, or Standard SQL from the dropdown. The dialect determines how reserved words and vendor-specific syntax like RETURNING or STRUCT are handled.
- 03
Set keyword case and indent
Pick UPPERCASE, lowercase, or Preserve for keyword casing. Choose 2 spaces, 4 spaces, or tabs for indentation. UPPERCASE keywords with 2-space indent is the most common style in shared codebases.
- 04
Click Format
The formatted output appears in the right panel instantly. Clauses are placed on their own lines, JOIN conditions are aligned, and subqueries are indented relative to their parent.
- 05
Copy and use
Click Copy to copy the formatted SQL to your clipboard. Paste into your IDE, a SQL file, a PR description, or a documentation snippet.
Safe to Use With Production Query Patterns
The sql-formatter library runs entirely in your browser. Nothing is sent to a server — no query text, no table names, no sample data. That makes it safe to format queries that reference real schema names or contain sample values from a staging database.
One thing the formatter will not do is execute your SQL. It's a text transformation tool only. You can safely paste queries that would drop tables or delete rows — the tool treats them as plain text and reformats them without running a single statement.
SQL Formatter FAQ
Which SQL dialects does this formatter support?
Standard SQL, PostgreSQL, MySQL, SQLite, and BigQuery. Each dialect handles vendor-specific syntax like PostgreSQL's RETURNING clause, MySQL's backtick identifiers, and BigQuery's STRUCT type correctly.
Will the formatter run my query?
No. It only reformats the query text. It doesn't connect to any database, validate column names, or execute statements.
Is my SQL uploaded to any server?
No. The sql-formatter library runs in your browser. Your query text stays on your device.
Why does my stored procedure or PL/pgSQL block format oddly?
Procedural SQL blocks (PL/pgSQL, BEGIN…END blocks, DECLARE sections) are outside what the formatter's grammar covers. Format smaller SELECT or DML snippets from within those blocks separately.
What's the best keyword case for a shared codebase?
UPPERCASE keywords are the most widely adopted convention — they visually separate SQL structure from identifier names. Two-space or four-space indentation is a matter of team preference.