Paste a minified SQL query and get readable, indented output. Choose the dialect, indent width and keyword case; everything runs locally in your browser.
Make a wall of SQL readable again. Paste a query - one line or a thousand - and it reformats as you type. Pick the dialect so that dialect-specific syntax is not mangled, then choose the indentation and keyword case your team uses.
The SQL formatting library failed to load. Please reload the page.
SQL is a standard in roughly the way English spelling is a standard. Every engine implements the common core and then adds syntax nobody else has, and a formatter that does not know which engine you are targeting will either misparse that syntax or silently pass it through unformatted.
The differences are not exotic. Identifier quoting alone splits the field: MySQL uses backticks, PostgreSQL and standard SQL use double quotes, and SQL Server uses square brackets. A formatter that assumes the wrong convention can treat a quoted identifier as a string literal and reflow the query around a boundary that does not exist. Beyond quoting there is LIMIT versus TOP versus FETCH FIRST, PostgreSQL's :: cast operator, T-SQL variables prefixed with @, BigQuery's backtick-wrapped project paths and Snowflake's QUALIFY clause. Picking the right dialect is what keeps those intact.
The indent width and keyword case look cosmetic, but they determine what your version control history looks like. Formatting is only useful when it is consistent, because the moment two people format the same file differently, every commit carries a wave of unrelated whitespace changes and code review stops working. Pick one configuration, write it into the repository, and apply it mechanically.
Uppercase keywords are the most common convention and they help when reading a dense query, because the structural words separate visually from your table and column names. Lowercase has gained ground in codebases that treat SQL as ordinary code and dislike shouting. Preserve is the right choice when you are formatting someone else's query and want to change the layout without touching a single character of their text, which makes the resulting diff purely structural.
Tabs versus spaces has the usual argument attached, with one SQL-specific wrinkle: queries frequently get pasted into terminals, ticketing systems and chat clients that render a tab as eight columns. A deeply nested query indented with tabs can wrap unreadably in exactly the places you are most likely to share it.
Formatting is purely presentational. It will not make a query faster, and it changes nothing about the plan the optimiser produces. A beautifully indented correlated subquery still runs once per row. Use EXPLAIN for performance work; use a formatter for legibility.
It also does not validate. This tool parses well enough to reflow the text, but it is not the engine's parser and it will happily format a query with a misspelled column or a missing join condition. A clean format is not a syntax check, and the only authority on whether a query is valid is the database you intend to run it on.
The one habit worth adopting alongside formatting is parameterisation. Formatting a query with values concatenated into the string makes the injection risk more readable but no less real. If you find yourself formatting SQL that contains user input spliced directly into the text, the formatting is not the problem worth fixing first.