SQL Formatter
Paste raw SQL and get it instantly formatted - keywords uppercased, major clauses on new lines, SELECT lists indented for easy reading.
- Free, no account
- No watermark
- No usage limit
About the SQL Formatter
Paste messy SQL, pick your database, get clean SQL back. It's free, it's instant, and it all runs in your browser, so nothing you paste ever leaves the tab. Type or paste on the left, the tidy version shows up below as you go.
Most free formatters treat every query as generic SQL. They uppercase the keywords, sprinkle in some line breaks, done. Fine, right up until your query has something database-specific in it, and then they either reformat it wrong or fall over. A Postgres :: cast, SQL Server's [Order Details] brackets, MySQL backticks, a BigQuery table path, Snowflake's QUALIFY. This formatter asks which database you're on before it touches anything. Twelve dialects, from the usual four down to Redshift, Spark, and DB2. Once the parser knows the dialect, it reads your SQL the way that engine actually does, so the odd syntax comes through intact instead of getting mangled.
How to use
- Paste your SQL into the Raw SQL box. Any casing, any spacing, one giant log line or a half-formatted mess, it all works the same.
- Set the dialect to the database you actually use. This is the step people skip, and it's the one that matters most (more on that just below).
- Choose the keyword case (UPPERCASE, lowercase, or Preserve) and the indent (2 or 4 spaces). The output re-formats live as you change either one, so you can just eyeball both until it looks right.
- Copy or Download. Copy drops the result on your clipboard and flips to "Copied!" for a second so you know it took. Download saves it as
formatted.sql, which is handy when the query is headed straight into a migration file.
Load sample fills the box with a real join-and-group query if you only want to see the shape it produces. Clear empties everything and starts you over.
Pick the dialect first, it matters
Set the dialect before you sit there wondering why the output looks off. It's the whole point of the tool.
Say you paste this Postgres snippet with Standard SQL still selected:
select id, price::numeric, created_at from orders where status = 'paid'
Generic formatters don't know what :: is. Some split it down the middle, some just bail. With PostgreSQL picked, the :: cast is a known operator and it stays glued together the way it should. SQL Server has the same kind of quirk. Square-bracket identifiers like [Order Details] are ordinary T-SQL and total gibberish to a plain ANSI parser. Pick SQL Server and they pass through clean.
The modern warehouse dialects are the real reason to reach for this over the free crowd. BigQuery, Snowflake, Redshift, Spark, DB2, each has its own quirks, and almost no quick browser formatter supports them at all. If your day is dbt models against Snowflake or scheduled queries in BigQuery, a generic formatter is a coin flip on whether it keeps your syntax. Here you pick the engine and the parser plays by that engine's rules.
If the tool shows a red parse error instead of formatted output, the query itself is usually fine. You've just got the wrong dialect selected. Syntax that's perfectly valid in, say, BigQuery will trip the Standard SQL parser and throw, because that grammar has never heard of it. Switch the dropdown to the matching database and the error clears. So a parse error usually means check the dialect, it rarely means your SQL is actually broken.
Uppercase, lowercase, or leave it alone
Old habit says uppercase every keyword, SELECT, FROM, WHERE, so the keywords stand out from your table and column names. It's still the most common style and it's the default here.
But the lowercase camp has grown up fast, mostly on the back of dbt and the modern data-stack style guides, which lean lowercase because editor syntax highlighting already does the job uppercase keywords used to do by hand. If your team writes lowercase SQL, flip Keyword case to lowercase and the formatter matches your house style instead of fighting it every time. And if you already have a casing you're happy with, Preserve leaves every keyword exactly as you typed it and only fixes the layout underneath.
Whichever case you choose, this one only re-cases the reserved keywords. Your identifiers are left exactly alone. A column you wrote as firstName stays firstName, a table named Orders stays Orders. That's the correct behavior and it is not a given. Plenty of quick formatters uppercase everything in sight and quietly break the casing on a case-sensitive Postgres column, which turns a "readable" query into one that won't even run, and that is not something this formatter will do to you.
Frequently asked questions
Does it handle CTEs and window functions, or just simple SELECTs?
It handles the messy stuff. A WITH block puts each CTE on its own, indented so you can follow where one ends and the next begins, and a window function keeps its OVER (...) clause laid out instead of flattened onto one unreadable line. Nested subqueries step in by depth too. Those are exactly the shapes a bare-bones formatter tends to butcher, and they're the reason picking the right dialect pays off, since the parser needs to understand the analytical syntax before it can lay it out cleanly.
Does it check whether my SQL is correct?
No, and it isn't trying to. It's a formatter, so it reshapes the layout and the keyword casing. It doesn't run your query or confirm the logic does what you meant. It does have to parse the SQL in order to format it, so a genuinely malformed statement can surface a parse error, but a query that parses cleanly will format even if it would return completely wrong rows. For real validation, run it against the database or use a proper linter.
Can it format several statements at once?
Yes. Separate them with semicolons and paste the whole block in one go. Each statement gets formatted on its own, so you can drop in a short migration or seed script and get the whole thing back tidy without doing them one at a time.
Why only 2 or 4 spaces for indenting?
Because those two cover nearly everyone, and a formatter buried under fifty options is slower to use than the messy query you started with. Two spaces is compact and common in modern repos, four is the roomier classic. Match whatever your codebase already uses so the formatted result drops in without adding noise to the diff.
Is any of my SQL sent to a server?
No. The parsing and the formatting both happen right in your browser. Your query never gets uploaded, there's no logging and no account, and once the page has loaded it keeps working even with the network switched off. That makes it safe for queries that name internal tables or hint at how your production data is shaped.
Which dialect should I pick if I'm honestly not sure?
Go with the database you're querying, that's almost always the right call. If you truly don't know, or the SQL is plain vanilla with no special operators, Standard SQL is the safe generic pick and handles the common SELECT, INSERT, UPDATE, and DELETE shapes everyone shares. You only need a specific dialect once the query leans on that engine's own syntax.
Will formatting change what my query returns?
It shouldn't. It only touches whitespace and keyword casing, never the logic or the values. String contents and comments come through untouched. The one thing to keep half an eye on is identifier casing on a case-sensitive engine, but since this tool leaves your identifiers alone, even that's rarely a problem in practice.