SQL Query Formatter

SQL is not one language, and that is the whole problem

The grammar is shared. The lexical layer is not, and the lexical layer is exactly what a formatter has to get right before it moves a single character. A quoted name is written with backticks in MySQL, double quotes in PostgreSQL and square brackets in SQL Server. A hash starts a comment in MySQL and is an operator in PostgreSQL. And a double-quoted run of text — the one that looks harmless — is a string in MySQL and anidentifier everywhere else.

That last one is not a curiosity. Consider "O'Brien". Read as a MySQL string, it is a name with an apostrophe in it and nothing is wrong. Read as an identifier, the apostrophe falls outside the quotes and every character after it in the file becomes an unterminated string. A ninety-megabyte export can be rendered useless by one punctuation mark, and the damage shows up thousands of lines later where nobody thinks to look.

What a SQL query formatter should tell you before it starts

Which dialect it decided you wrote. Every tool in this category picks one, and almost none of them say so — one of the best-known free formatters handles Transact-SQL exclusively and mentions it nowhere on the page, so the first thing you learn is that your LIMIT clause came back mangled.

Here the guess is a sentence with its evidence in it: read as MySQL, because of backtick quoting on line 3. You can disagree and change it. And when nothing in the text points anywhere in particular, it says that instead of pretending — a query that uses only standard syntax genuinely has no dialect, and claiming otherwise would be inventing information to look confident.

The rule that matters more than the layout

Nothing may disappear. The tokenizer that reads your SQL guarantees that every single character lands in exactly one token, and the formatter is only permitted to change the whitespace between tokens and, if you ask, the case of keywords. There is a test that reassembles the tokens and compares them to the original byte for byte.

The consequence is that anything unrecognised passes through untouched and gets counted. MySQL dumps carry executable comments — text that looks like /*!40101 … and is a comment to every other engine but real, running code to MySQL. Warehouse dialects carry clauses like QUALIFY. A PostgreSQL function body is dollar-quoted and may contain entire statements that must not be reindented. A formatter that guesses at any of these has damaged your file rather than tidied it, and you find out when you try to restore from it.

Line breaks belong to clauses, not to a column counter

This is what makes formatting SQL different from formatting most languages, and it is why there is no maximum line width setting here. A SELECT with forty columns should be forty lines. Every clause starts one — FROM, WHERE,GROUP BY — while AND and OR sit indented beneath the clause they qualify, so the shape of a long predicate is visible at a glance.

A few things are deliberately kept together because splitting them helps nobody:LEFT OUTER JOIN is one line rather than three, and INSERT INTOand DELETE FROM stay whole. Leading commas are available for the people who want them, which is most of the argument anybody has ever had about SQL style.

Minifying is the same decision, pointed the other way

It is the bottom option on the indent control rather than a separate mode, because that is what it is. Comments go, runs of whitespace collapse, and string literals are left exactly as they were. That last part is where naive minifiers fail: a comment-closing sequence sitting inside a quoted string looks like the end of a comment to anything working with regular expressions, and half the statement vanishes. It cannot happen here, because by the time anything is removed the string is already a single indivisible token.

A query is not neutral text

It contains your table names, your column names and the shape of your schema. Very often it contains a real value out of production sitting in a WHERE clause — an email address, an order number, an identifier belonging to an actual person. Every other free SQL formatter on the web takes that and posts it to a server.

This one does not, because it cannot: the tokenizer and the formatter are JavaScript running in this tab. There is no upload endpoint. You can check that the way you would check anyone's claim — open your browser's network panel, paste your query, and watch nothing leave.

Large files, including whole dumps

A .sql export from a backup is the largest text file most people ever handle, and it is precisely the case a paste box was never going to serve. Drop the file instead. Nothing here refuses a file for its size, and work that grows with the file runs off the main thread so the page stays responsive while it happens.

Errors do not stop the run either. An unterminated string is reported with its line and column, and everything else is still formatted — throwing away a whole export because of one stray apostrophe on line forty thousand would be a strange way to help.

If what you actually want is the data rather than the layout, the same tokenizer drivesSQL to CSV, which lists every table in a dump with its row count and lets you export the columns you tick. Going the other way,CSV to SQL builds the statements from a spreadsheet export.