🗄️ SQL Formatter
Beautify or minify SQL queries with proper indentation. Supports SELECT / INSERT / UPDATE / DELETE / JOIN / WITH.
🔗 Related Tools
📖 Where people get stuck
Format SQL for readability, or minify it. Everything runs in the browser and the query is not transmitted. This changes the layout only; it does not validate the syntax — a query that will not run gets formatted just the same, and dialect-specific constructs in MySQL, PostgreSQL or SQL Server can come out oddly laid out. Treat running it as part of the same step.
| Case | What happens | What to do |
|---|---|---|
| The result changed after formatting | The usual cause is how comments and string literals are treated. A -- comment runs to the end of the line, so changing where the line breaks changes what is commented out. The moment a formatter splits one line into several, a live condition can disappear into a comment — or escape from one. Likewise, collapsing whitespace inside a string literal changes what LIKE matches. |
Write comments as /* … */ rather than --: the extent is explicit, so reflowing the lines cannot change the meaning. To be sure nothing shifted, compare the EXPLAIN plan before and after. If the plan is identical, the queries are the same as far as the optimiser is concerned. |
| Pasting the formatted query straight into code | When you paste the now-readable SQL into code as a string, interpolating values by concatenation is SQL injection. While formatting you are working with a query that has literal values in it, which makes turning it into "WHERE id = " + id the path of least resistance. Passing a query through a formatter is exactly the moment this mistake tends to happen. |
Always use placeholders for values: WHERE id = ? or WHERE id = :id, with the value handed to the driver. What placeholders cannot cover is table names, column names and the ORDER BY direction; resolve those against an allowlist, permitting only ASC or DESC and nothing else. Make it a habit to scan the formatted query for leftover literals while it is still readable. |
| Formatting does not make a slow query fast | Obviously enough, formatting has no effect whatsoever on the execution plan. It can make the cause visible to you, but that is a benefit to the reader, not the database. Most slow SQL is slow because an index is not being used, which has nothing to do with how tidily the query is written. | Run EXPLAIN ANALYZE and look at how many rows were actually read. Scanning a million rows to return ten tells you where the problem is. A common culprit is wrapping the column in a function in the WHERE clause — WHERE DATE(created_at) = ... — which disables the index; rewriting it as a range, WHERE created_at >= ... AND created_at < ..., brings it back. Dropping SELECT * for just the columns you need can also let a covering index take over. |
If the goal is a consistent style across a team, put a linter in the repository rather than formatting here each time. A tool such as sqlfluff covers not just layout but naming conventions and dangerous constructs — SELECT *, an UPDATE with no WHERE. Run it in CI against your migration files and review comments shift from readability to design. This page earns its place when someone hands you an unreadable query and you need it legible once, right now.
📖 How to Use
-
1
Set action and optionsChoose beautify or minify, then set indent size and keyword casing (UPPERCASE, lowercase, or preserve).
-
2
Enter your SQLPaste your SQL query into the left input. Click Sample to load a complex example with SELECT, JOIN, and subqueries.
-
3
Copy the resultThe formatted or minified SQL appears on the right. Click Copy to copy it to your clipboard.
❓ Frequently Asked Questions
Which SQL dialects are supported?
Are comments preserved?
Are string literals modified?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.