Online SQL formatting tool: supports MySQL, PostgreSQL, SQLite, BigQuery dialects. Uppercase/lowercase keywords, configurable indentation. Format or minify SQL statements instantly.
TL;DR: Free online SQL formatter supporting MySQL, PostgreSQL, SQL Server, and more. Custom indent and keyword casing, runs locally in your browser.
For local tools, open DevTools → Network and search your input — it should not appear in requests.
Usage Guide
A colleague hands you a query with twelve conditions packed into three lines, or you dig a 2000-character statement out of logs — formatting is the first step to reading it. This tool re-indents and line-breaks by dialect, normalizes keyword case, and can minify to one line, entirely locally; query content stays in your browser.
1. Format a query
- Paste the SQL (a squashed one-liner or inconsistently indented lines both work).
- Pick the dialect: Standard SQL, MySQL, PostgreSQL, SQLite, or BigQuery — the dialect affects keywords and identifier quoting habits.
- Tune indent width and keyword case to team taste (UPPER separates keywords from columns), format, copy; use minify for logs or single-line configs.
2. Two kinds of "bad SQL" formatting cannot fix
- SELECT * with twelve JOINs performs no better for being pretty — formatting makes it readable; the execution plan still needs EXPLAIN.
- Implicit type casts and functions wrapped around columns (WHERE YEAR(created) = 2024) are index killers — formatting exposes them clearly, but only a rewrite fixes them.
3. The team workflow that actually works
Make "format before you commit" a team convention: nobody wants to read layout noise in review, and formatting changes mixed into a diff drown the real logic changes. Pair it with the SQL Playground on this site — format to clean up legacy queries, Playground to validate new ones.
4. Why dialect matters
Backticks, double quotes, and brackets mean different things across engines; LIMIT/OFFSET, TOP, and FETCH are not interchangeable. The wrong dialect may still "pretty-print", but keyword case and break points may not match your target engine. When unsure, start from Standard and fine-tune. This page covers the five dialects above — not every vendor extension.
5. A formatting checklist before review
- Format before reading WHERE/JOIN clauses so ORs are not hidden on one line.
- Aligned subqueries and CTEs make "filter applied at the wrong level" easier to spot.
- When pasting formatted SQL into a diff, keep layout changes out of the same commit as logic changes.
6. Safety note for SQL from logs
SQL copied from production logs may contain business literals (phone numbers, emails, order payloads). This page does not upload them, but pasting into chat or tickets still leaks. Redact before sharing; for repeated debugging, prefer parameterized examples over full statements with real data.
7. Dialects and parse errors
Format for MySQL, PostgreSQL, SQLite, BigQuery, and related dialects; keyword case and indent follow options. On parse failure, use line/column hints and strip unsupported vendor syntax. This page formats only — it does not run SQL against a database.
FAQ
Yes — the formatting itself never leaves your browser. But literals such as phone numbers, emails, and order contents are not scrubbed automatically: redact before sharing to chat or tickets, and for queries you'll debug repeatedly, rewrite them as parameterized examples instead.
Five dialects today: Standard SQL, MySQL, PostgreSQL, SQLite, and BigQuery. You can tune indent width and keyword case (uppercase makes keywords stand out from column names) and minify to a single line. Dialects change keyword and identifier-quoting conventions; when unsure, start with Standard.
Backticks, double quotes, and brackets mean different things per engine, and LIMIT/OFFSET, TOP, and FETCH aren't interchangeable. The wrong dialect sometimes still formats, but line breaks and quoting conventions won't match the target engine; when a proprietary function formats oddly, check the dialect first. The five dialects above don't cover every vendor extension.
No. A SELECT * pile with a dozen JOINs won't run faster for being pretty — execution plans still need EXPLAIN. Readability does help spot index killers like functions wrapped around columns (WHERE YEAR(created) = 2024) or implicit type conversions, but fixing them still requires rewriting the query.
Agree on format-before-commit; formatting noise mixed into a diff buries the real logic changes. Format before reading WHERE/JOIN conditions in review — an OR squeezed onto one line, or a filter placed at the wrong subquery level, surfaces more easily once indentation lines up. Pair it with the site's SQL Playground: format old queries here, validate new ones there.
When squeezing a statement into a single-line log field or a config entry that accepts one line only. For humans and reviews, always use the formatted output — reviewers can trace JOINs and filters by indentation instead of scrolling sideways through one long line.
Related Tools
Related Articles
Online SQL Formatter: Beautify and Minify SQL Queries
Format and minify SQL by dialect (MySQL, PostgreSQL, SQLite, BigQuery). Diff-conscious layout, ORM log cleanup, and what a formatter will not fix. Pairs with CSV→SQL.
Online Code Formatter: Beautify JavaScript, HTML, CSS, and SQL
Use a browser-local code formatter for JavaScript, HTML, CSS, and SQL — indent options, parse error line numbers, Format vs Minify size deltas, and how it splits work with IDE Prettier.
Online CSV to SQL Tool: Import Tabular Data into Databases
CSV to INSERT with empty cells → NULL, MySQL backticks or PostgreSQL quotes, BOM stripping, Markdown pipe escaping, and when to switch to COPY/LOAD instead.