SQL Formatter

Turn one long line of SQL into something you can actually read. The layout changes; the query does not — and anything inside quotes or a comment is left exactly as you wrote it.

Formatted


          
—Lines
—Tokens
—Deepest nesting

What it does

Each major clause — SELECT, FROM, WHERE, each JOIN, GROUP BY, ORDER BY — goes on its own line. The columns you are selecting go one per line underneath. Every AND and OR starts a new line, so a long condition stops being a wall of text. Brackets indent what is inside them.

That is the whole job. Reading a query is most of the work of fixing one, and a query written as a single 300-character line hides its own shape.

It changes the layout and nothing else

No clause is reordered, no bracket added or removed, no SELECT * expanded, nothing optimised. Run the output and you get exactly what you got before. That is a deliberate limit: a formatter that improves your query is a formatter you have to read the output of, which defeats the point.

Two things are copied through untouched. Text in quotes — 'Hyderabad' stays 'Hyderabad', and a keyword inside a string is just a word, not a keyword. And comments, both the -- and the /* */ kind, keep their contents exactly, because a comment often holds a note nobody wants reflowed.

Capitals are a convention, not a rule

SQL does not care. select and SELECT are the same word to every database. Capitals are a habit from the days before syntax colouring, and they still do a useful job: in a plain black-and-white diff or a log file, they are the only thing marking where the structure is. Turn them off if your team writes lower-case.

Your table and column names are never touched, in either direction. Some databases treat names as case-sensitive, and changing one is the sort of bug that appears only on the production server.

It does not know your dialect

It lays out the shapes common to every SQL there is. It has not been taught the extras that belong to one database and not another — window functions with long OVER clauses, MERGE, vendor-specific hints. Those come through correctly, just not laid out cleverly. If the result of formatting looks wrong to you, trust yourself: the query is unchanged, only the spacing is this page's opinion.

Frequently asked questions

Does it change what my query does?

No. Only whitespace and, if you ask for it, the capitalisation of keywords. Nothing is reordered, added or removed, so the formatted query runs exactly as the original did.

Are the words inside my strings capitalised too?

No. Anything between quotation marks is copied through untouched, so a value like 'select' stays lower-case. The same goes for everything inside a comment.

Will it uppercase my table names?

Never. Only recognised SQL keywords change case. Some databases treat identifiers as case-sensitive, so altering one would be a way to break a query that worked yesterday.

Why is my window function laid out oddly?

Because it lays out the shapes common to all SQL and has not been taught every dialect's extras. The query is unchanged - only the spacing is this page's opinion, and you are free to disagree with it.

Can it minify SQL instead - put it back on one line?

Not here. There is very little reason to: a query is sent once and the database does not care about whitespace, so making it unreadable saves nothing worth having.

Is my text sent anywhere?

No. Everything happens in JavaScript inside your own browser. Nothing is uploaded and nothing is saved - close the tab and it is gone.

Related tools