SQL Formatter

It takes a SQL query — however cramped, however it was pasted — and lays it out cleanly, with each clause on its own line and consistent indentation, so it is easy to read and review. You choose the dialect, whether keywords are upper-cased, and how far things are indented. It is for tidying up queries you are writing, debugging, or pasting into documentation and pull requests, so they read the way well-kept SQL should.

Standard SQL plus the dialects most people actually use: MySQL, MariaDB, PostgreSQL, SQLite, SQL Server (T-SQL), Oracle (PL/SQL), BigQuery, Snowflake, Redshift, Spark SQL and Db2. The dialect matters because each one has its own keywords and quirks of syntax — picking the right one means the formatter understands constructs specific to your database and lays them out correctly rather than tripping over them.

It controls how SQL keywords like SELECT, FROM, WHERE and JOIN are capitalised. “Upper” shouts them in capitals, which is the most common house style and makes the structure of a query jump out. “Lower” puts them in lower case for a softer look. “Preserve” leaves them exactly as you typed them. Crucially, this only ever changes keywords — your table names, column names and string values are left exactly as they are.

No. Formatting only changes layout — line breaks, indentation and the spacing around operators — plus the capitalisation of keywords if you ask for it. Your table and column names, string and number literals, comments and the logic of the query are all preserved untouched. The reformatted query is the same query, just laid out clearly. The one thing to know is that SQL keyword case is cosmetic, but identifiers in some databases can be case-sensitive — and those are never altered.

It does not run anything and never connects to a database, so it cannot tell you whether a table or column exists or whether the query returns what you expect. It does, however, have to parse the query in order to format it — so if the syntax is broken it will tell you, and point you to the line and column where parsing failed. Think of it as a syntax-level sanity check that comes for free with the formatting, not a full validator.

No. The query is parsed and formatted entirely in your browser — nothing you paste is sent to a server, which you can confirm in your browser’s network panel. That matters for SQL in particular, since queries often contain table names, logic or example data you would not want to send to a third party. The optional share link stores the query in the URL itself rather than on a server, and the on-device history can be cleared whenever you like.