How to format SQL
Paste your query into the input pane on the left and the formatted version appears on the right as you type — no button to press. Pick the dialect that matches your database so keywords and syntax are recognised correctly, choose whether keywords should be UPPERCASE, lowercase or left as written, and set the indentation to 2 spaces, 4 spaces or a tab. Copy the result with one click or download it as a .sql file. If the input cannot be parsed, the status line explains what went wrong instead of returning a broken result. Everything runs in your browser; nothing is uploaded.
Why format SQL at all?
SQL is written far more often than it is read carefully, and a query that works is not the same as a query that is reviewable. A single-line SELECT with a dozen columns, three joins and a nested subquery is technically valid and almost impossible for a human to scan. Formatting turns that wall of text into a structured shape: one column per line, joins aligned, WHERE conditions stacked so the logic is obvious at a glance. That clarity matters most exactly when the stakes are highest — during code review, when debugging a slow query, or when you inherit a report someone wrote years ago and need to understand it before you change it.
Consistent formatting also reduces noise in version control. When everyone on a team beautifies SQL the same way, a diff shows the real change — a new condition, a renamed column — instead of a reshuffle of whitespace. Migrations, stored procedures and analytics queries all benefit from being committed in a canonical shape. Because this tool is deterministic, the same input and the same options always produce byte-for-byte the same output, which is what makes it safe to run as a pre-commit step or paste into a shared style guide.
Dialects and formatting options
SQL is a family of related languages, not one language. Standard SQL is the common core, but every engine adds its own keywords, functions and quoting rules. PostgreSQL uses :: casts and dollar-quoted strings; SQL Server speaks T-SQL with square-bracket identifiers and TOP; BigQuery has backtick-quoted names and array syntax; Oracle PL/SQL has its own procedural blocks. Selecting the right dialect tells the formatter which words are reserved keywords and how to treat that engine's syntax, so the output is both pretty and correct for your target database. This tool supports Standard SQL alongside PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle (PL/SQL), BigQuery, Snowflake, Redshift, Spark SQL, Db2, Hive, Trino/Presto and DuckDB.
Two style controls cover the choices teams argue about most. Keyword case lets you uppercase keywords for the classic SQL look, lowercase them for a modern code-like style, or preserve exactly what you typed. Indentation picks 2 spaces, 4 spaces or a tab to match the rest of your codebase. The defaults — uppercase keywords, two-space indent — match the most widely used convention, so for most people the tool is correct the moment the page loads.
Formatting is semantically safe
A formatter must never change what a query means, only how it looks. This tool works by tokenising the statement and re-emitting those exact tokens with new whitespace and keyword casing — it does not rewrite expressions, reorder clauses, add or drop conditions, or touch the contents of string and numeric literals. The identifiers you wrote stay byte-for-byte identical, and a comment in your SQL is carried through to the output. The result is a query that is guaranteed to be equivalent to the one you pasted: easier to read, identical to run.
Multiple statements are handled the same way. Paste a whole script of semicolon-separated statements — a migration, a batch of inserts, a setup file — and each statement is formatted in turn with a blank line between them, so the script stays organised without any statement bleeding into the next.
Why a local SQL formatter matters
The SQL you most want to tidy is rarely generic. It names your real tables, your real columns, your reporting schema; sometimes it contains literal values pulled from production, customer identifiers in a WHERE clause, or a connection note in a comment. Pasting that into a random online formatter or a chatbot ships your internal data model — and occasionally live data — to a third-party server you do not control. For many teams that is a policy violation before it is anything else.
This tool removes the risk entirely. The formatting engine is a bundled JavaScript library that runs inside your own browser tab. There is no network request when you format, no logging, and no account. Close the tab and everything you pasted is gone. That is the gitime.dev approach across the board — deterministic, dependency-light developer tools that keep your data on your machine, because tidying a query never needs to leave your device to happen.
- 15+ dialects: Standard SQL, PostgreSQL, MySQL, T-SQL, BigQuery and more.
- Configurable keyword case and 2/4/tab indentation.
- Semantically safe: only whitespace and casing change, never the logic.
- Multi-statement scripts formatted statement by statement.
- Everything stays on your device — no upload, no logging.
Frequently asked questions
- Is my SQL uploaded anywhere?
- No. Formatting runs in your browser with a bundled copy of the sql-formatter engine. Nothing is transmitted.
- Which SQL dialects are supported?
- Standard SQL plus PostgreSQL, MySQL, MariaDB, SQLite, T-SQL, PL/SQL, BigQuery, Snowflake, Redshift, Spark, Db2, Hive, Trino/Presto and DuckDB.
- Does formatting change what my query does?
- No. Only whitespace and keyword case change; tokens, identifiers and literals are preserved, so the query is equivalent.
- Can it format multiple statements at once?
- Yes. Semicolon-separated statements are each formatted, with a blank line between them.