SQL -> READABLE · Local tool
SQL Formatter
Format SQL with proper clause indentation and keyword casing.
Last updated
How do I format SQL to make it readable?
Paste the query into filetity's SQL formatter and it comes back with each clause on its own line and the select list, join conditions and boolean chains indented under them, all inside the browser tab with nothing uploaded. The query is tokenised before any formatting happens, so a string, a quoted identifier, a comment and a Postgres dollar-quoted function body are each one token nothing looks inside, which is why a column named select and the word from inside a string literal both survive. Keywords can be uppercased, lowercased or left exactly as typed. It formats rather than validates: a broken query still comes back laid out, with the line and column where it lost the thread, and formatting twice gives the same text so it will not churn a file in version control.
01 / Your device
the file stays here
02 / Browser memory
the work runs locally
03 / Back to you
saved on this device
When you would use this
Situations, not settings.
- A query somebody pasted as one enormous line
- Out of a log, an ORM or a chat message. Clause indentation is the difference between reading it and rewriting it.
- A query you are about to commit
- Formatting twice gives the same text, so putting this in front of a file does not produce a diff every time somebody runs it.
- Finding the bracket you did not close
- A broken query still comes back laid out, with the line and column where the formatter lost the thread, which is exactly when you needed to read it.
How it works / no cloud
A conversion engine, not an upload form.
The query is tokenised before anything is formatted, so a string, a quoted identifier, a comment and a Postgres dollar-quoted body are each one token that is never looked inside. That is why a column called "select" and the word from inside a string literal both survive, which is where most SQL formatters corrupt a query.
- Offline ready
- Installable app
- No file limit queue
Straight answers
No accordion. Nothing hidden.
- Is it free?
- Yes, with no watermark and no page limit.
- Does it need an account?
- No. There is no account system.
- Is my file processed on my device?
- Yes. The file is read by your browser and never uploaded. There is no server to send it to.
- What formats are supported?
- SQL in, any dialect. Formatted SQL out, with keywords upper, lower or left alone, and two or four space indentation.
- What are the limits?
- This is a formatter rather than a validator. Every token you type comes back in the original order, and anything it cannot parse is reported with a line and column and printed unharmed.
- Does it work on mobile?
- Yes, on any modern mobile browser. Large files are limited by the memory the phone gives the browser.
- Does it work offline?
- Yes, once the page has loaded. The tool keeps working with no network connection.
- Will it break a query with the word FROM inside a string?
- No, and this is the thing worth checking in any SQL formatter. Strings, quoted identifiers in every dialect's style, comments and Postgres dollar-quoted bodies are each read as one token before formatting starts, so nothing inside them is treated as a keyword or re-cased.
- What happens if my SQL has a syntax error?
- It still comes back, laid out as well as it can be, with the line and column where the formatter lost the thread. A missing bracket or a CASE with no END is reported rather than thrown, because a formatter that refuses to format the broken query is refusing exactly when you needed to read it.
- Is the output stable if I run it twice?
- Yes, and that is tested rather than hoped for. Formatting an already formatted query returns exactly the same text, so putting this in front of a file in version control does not produce a diff every time somebody runs it.
- Which dialect does it assume?
- None in particular, which is why it handles backtick identifiers from MySQL, bracketed ones from SQL Server and dollar quoting from Postgres in the same pass. Anything it does not recognise is left as words rather than being reshaped into something it might not be.
- Does it uppercase my column names?
- Only if they are reserved words, and that is cosmetic because every database folds unquoted identifiers anyway. Words like name, value, date and type are treated as identifiers rather than keywords, since they are columns far more often than they are anything else.
Keep working locally
3 available · more coming