SQL Formatter

SQL Formatter turns dense, single-line or inconsistently written SQL into readable, review-friendly queries. It puts each major clause - SELECT, FROM, WHERE, JOINs, GROUP BY, ORDER BY, HAVING, LIMIT, UNION - on its own line, breaks SELECT columns onto separate lines, indents AND/OR conditions under their clause, and normalizes keyword casing to upper or lower. The result is the kind of layout you would want in a code review: a 400-character query from an ORM log becomes a structure you can scan for the missing join condition.

As a SQL query formatter it takes a line like select top 10 [Order ID], total from dbo.[Order Details] where total > 100 and status = 'open' and returns SELECT TOP 10 on the first line, [Order ID] and total on their own indented lines, then FROM, then WHERE with the AND condition indented under it. SQL Server users can treat it as a SQL formatter for SSMS: format the T-SQL in this online SQL formatter, then paste it back into SQL Server Management Studio. It is a web page, not an SSMS extension, so there is nothing to install.

Under the hood it is a real tokenizer, not a pile of find-and-replace rules. String literals (including doubled-quote and backslash escapes), double-quoted and backtick-quoted identifiers, bracketed SQL Server identifiers, numbers, operators and both comment styles (-- line and /* block */) are lexed as atomic tokens before any layout decision is made. That means a column value like 'SELECT * FROM users' inside a string is never mistaken for a clause, and formatting can restructure whitespace without ever corrupting literal content.

The Minify mode does the opposite: it collapses a formatted query to a single line - dropping comments, preserving every literal byte-for-byte - which is handy for log grepping, packing queries into JSON payloads or .env files, and comparing query shapes. Everything runs client-side in your browser, so production queries containing table names, customer data in literals or schema details are never uploaded, logged or stored anywhere.

Formatting is tokenizer-based rather than regex-based, so string literals and comments containing SQL keywords are not reformatted as if they were code. Dialects still differ in ways no formatter can settle, particularly around quoting identifiers, so the output is normalised rather than guaranteed portable.