A one-line SQL query is a riddle; the same query with its clauses on separate lines is a document. This SQL pretty printer reformats raw SQL the way experienced developers write it: SELECT, FROM, WHERE, each JOIN, GROUP BY and ORDER BY start their own line, conditions line up under WHERE, and keywords are uppercased so the structure jumps out.
It works from a real tokenizer, not find-and-replace, so text inside string literals is never mistaken for a keyword — a note column containing the words “from the where clause” survives formatting untouched. Everything runs locally in your browser.
What “pretty” means for SQL
Readable SQL follows a layout, and the layout is information. Major clauses begin at the left margin, one per line, so the eye can decompose any query in a second: these columns, from these tables, filtered by these conditions, grouped and ordered like so. Conditions after the first align under the WHERE block on their own AND/OR lines, because a buried OR at the end of a 200-character line is how wrong reports happen. Keywords in one consistent case — uppercase by convention — separate the grammar of the language from the names of your tables and columns. This formatter applies exactly that layout, and if your house style is lowercase keywords, the toggle switches it.
A worked example
Take the sample query jammed onto one line: select id, name, email from users where age > 30 and city = 'Oslo' order by name. Formatted, it becomes five short lines with the column list on the SELECT line, the table on FROM, and the second condition standing visibly on its own AND line. Nothing about the query’s meaning changed — but now the next person (often you, in three months, at 2 a.m.) can see what it does at a glance and where a new condition belongs.
Why a tokenizer matters
The naive way to build a formatter is regular expressions over the raw text, and it fails the moment real data appears: replace the word “from” and you have also rewritten someone’s note that says from the where clause. This tool first splits the query into tokens — words, numbers, punctuation, and string literals kept whole — and formats the token stream, so quoted text is cargo, never code. The same care applies to compound operators (>=, <>, !=), which stay glued together as they should.
Honest limits
A formatter is not a validator: it will happily lay out a query that references a table that does not exist, and it will not repair genuinely broken syntax — it formats what parses as tokens and leaves the rest readable but unchanged in meaning. Exotic dialect syntax (vendor-specific hints, unusual quoting) may not get the full clause treatment; the output is still the same query, just less decorated. And formatting is not optimisation: a beautifully printed slow query is still slow.
Frequently asked questions
Which SQL dialects does it support?
The clause layout is dialect-agnostic — SELECT/FROM/WHERE/JOIN/GROUP BY/ORDER BY/HAVING/LIMIT read the same in MySQL, PostgreSQL, SQL Server, SQLite and BigQuery. Quoted identifiers in double quotes or backticks are tokenised safely in all of them.
Does it change what my query does?
No. Only whitespace and (optionally) keyword case change. Case is insignificant for SQL keywords in every major dialect, and string literals are preserved character-for-character, case included.
Can it format INSERT and UPDATE statements?
Yes — INSERT INTO … VALUES, UPDATE … SET and DELETE FROM get the same clause-per-line treatment.
Is my query uploaded?
No. Tokenizing and formatting happen in your browser tab — safe for queries that mention internal tables and columns.
Related tools
Versión en español: Formateador de Consultas SQL — Da Formato a tu SQL Online y Gratis. You may also like: JavaScript Array Formatter — Turn Any List into a JS Array Online.
Embed this tool on your website — free
Copy the code below to add this working tool to your own page. A small credit link stays with it — that’s all we ask.