Everything runs on your machine — your file is processed right here in your browser and never uploaded to any server.
InputSQL
Loading...
OutputSQL
Loading...

About this tool

Long SQL rarely stays readable. Queries generated by ORMs arrive as a single line, reporting queries grow subquery upon subquery, and a statement copied out of a log file loses whatever formatting it once had. This formatter takes messy SQL on the left and pretty-prints it on the right, giving keywords, clauses and indentation a consistent layout so you can actually follow what a query joins, filters and returns.

Different databases speak different flavors of SQL, so the toolbar includes a dialect selector covering standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, T-SQL for SQL Server, and BigQuery. Picking the right dialect means engine-specific syntax is understood and laid out correctly, and switching the dropdown reformats the query on the spot. It is a quick win before a code review, when pasting a query into documentation, or while untangling a slow statement someone wrote three jobs ago.

How to use

  1. Paste your query into the left editor, or click Load File to open a .sql file.
  2. Choose your database from the dialect dropdown in the toolbar, such as PostgreSQL, MySQL or BigQuery; the output reformats immediately when you change it.
  3. Read the formatted result in the right editor, which updates live as you edit the input.
  4. Click Copy to paste the clean version into your codebase, or Download to save it.
  5. Hit Clear to empty both panes when you are done.

Queries frequently reveal table names, column names and business logic, which is exactly why this formatter runs with no backend at all. The text is restructured by JavaScript inside your browser and never travels over the network, so proprietary schemas stay private.

Frequently asked questions

Does the formatter validate my SQL or check it against my schema?

No. It rearranges whitespace, indentation and keyword layout without executing the statement or knowing anything about your database. A query can format beautifully and still contain a typo, reference a missing table or fail at runtime, so validation still belongs in your database client.

Will formatting change what my query actually does?

The formatter only changes presentation, meaning line breaks, indentation and keyword layout. The logic of the statement, its identifiers and its literal values are left intact, so the formatted query behaves the same as the original when you run it.

Why does the dialect setting matter?

Each database extends SQL differently: T-SQL has square-bracket identifiers, PostgreSQL has its own casts and operators, and BigQuery adds constructs like STRUCT. Selecting the matching dialect lets the formatter parse those extensions properly instead of tripping over syntax it does not recognize.