SQL Formatter

⚡ Runs locally🔒 No uploads🆓 Free, no sign-up

A SQL formatter does one simple thing: it takes a query crushed into a single line and re-lays it out according to its grammatical structure. The process has four stages. First, lexical protection: string literals and comments are stashed behind placeholders so not a single character inside them can be touched. Second, keyword recognition, case-insensitive — select and SELECT are treated identically. Third, clause breaking: SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY and LIMIT each start on their own line. Fourth, parenthesis indentation: subqueries and function arguments unfold one level at a time. Uppercasing keywords is purely cosmetic — SQL keywords are case-insensitive, so it only makes the structure pop; it changes nothing about semantics. One honest caveat: this tool is a lightweight lexical formatter, not a full SQL parser. It handles layout, not correctness — a broken query stays broken after formatting, just more readable.

Three scenarios cover most real usage. First, reading someone else's SQL: you copy a 400-character one-liner out of a slow-query log or an ORM debug dump, paste it here, and suddenly JOIN conditions, WHERE filters and GROUP BY clauses each sit on their own line — the bottleneck reveals itself in seconds. Second, debugging SQL errors: a missing comma or an unbalanced parenthesis is the most common rookie mistake, and after formatting the indentation visibly breaks exactly where the problem is, far faster than counting parens by eye. Third, code review and documentation: paste formatted SQL into a PR description, a wiki page or a postmortem. Reviewers no longer have to wrestle with a wall of single-line text, and the diff in a review actually becomes reviewable.

Know the boundaries. Strings and comments are safe zones: the and inside a LIKE pattern will never be treated as a logical keyword and broken onto a new line, and a SELECT inside a comment will not be uppercased. The flip side is that the tool cannot spot mistakes inside your strings either. Dialects: standard SELECT/INSERT/UPDATE/DELETE syntax works across MySQL, PostgreSQL, SQLite and SQL Server. Dialect-specific constructs — T-SQL's TOP n, SQL Server's bracketed identifiers — pass through untouched as plain tokens; formatting still works, but there is no syntax validation. Huge queries (tens of thousands of lines) run fine in the browser, just a second or two slower. Comments are preserved when formatting; they are stripped on minify, because a line comment collapsed onto one line would comment out everything after it — removing them is protecting you. Keyword uppercasing can be toggled off if you only want line breaks and indentation.

Two final notes. First, formatting changes only whitespace, line breaks and keyword case — zero logic change. Diff the output against your original once and you will see; execution results are identical. Second, pretty layout cannot save a slow query: formatting is step one — understanding the SQL. After that it is indexes, rewrites and query plans, which is a different job.