SQL Formatter

An SQL Formatter (also called an SQL Beautifier or SQL Pretty Printer) turns dense, unreadable SQL into a structured layout with indentation, keyword casing, clause line breaks, preserved comments, and statement separation. It makes queries easier to read, review, debug, and commit — without executing the SQL or connecting to a database.

Paste SQL into the input editor or open a local .sql, .ddl, or .dml file. Choose a dialect hint, indentation style, keyword casing, comma layout, AND/OR line placement, blank-line spacing, comment policy, and statement splitting. Click Format SQL or press Ctrl+Enter to see the result, then copy or download it.

The formatter provides 10 dialect hints: Generic SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server / T-SQL, Oracle / PL-SQL, BigQuery, Snowflake, and Amazon Redshift. Each dialect unlocks additional recognized keywords so casing and clause detection are more accurate for that vendor. The hints do not claim complete parser compatibility or vendor-specific grammar validation.

No. The formatter never connects to a database, sends a query to a server, runs SQL, reads schemas, or checks permissions. All tokenizing and layout work runs locally in your browser tab. You can open DevTools → Network and verify zero outbound requests.

Yes. Single-quoted strings, double-quoted identifiers, backtick-quoted names, dollar-quoted strings ($$...$$), line comments (--), and block comments (/* */) are all tokenized before formatting. Keywords inside strings are never recased. Semicolons inside quoted strings never trigger statement splitting.

Recase Only applies keyword casing (UPPERCASE, lowercase, or Preserve) without changing any whitespace or indentation. It is useful when you want to normalize keyword casing across a query without reformatting its layout — ideal for code reviews or style-guide enforcement on existing formatted SQL.

Minify strips all whitespace, indentation, and comments to produce the most compact single-line SQL possible. This reduces file size for embedded SQL strings, log payloads, or wire-format query serialization. Semicolons inside quoted strings are still protected.

Yes. The Comma setting offers three options: Inline (comma stays at end of each value, same line), New line trailing (comma at end, clause moves to next line), and New line leading (comma placed at the start of the next line — the "leading comma" style popular in many SQL style guides).

Yes. The formatter places readable breaks around SELECT, FROM, JOIN, ON, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, OFFSET, UNION, WITH, VALUES, SET, RETURNING, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, and TRUNCATE when the token context permits. Multi-word JOIN modifiers (LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN etc.) are kept together on one line.

Yes. Parenthesis depth is tracked to handle nested expressions, function calls, subqueries, IN lists, CASE expressions, and VALUES lists. Common Table Expressions using WITH and RECURSIVE are detected as major clause boundaries. The review panel warns when parentheses are left open.

Yes. The Blank lines setting lets you add 0, 1, or 2 blank lines between semicolon-delimited statements. This is useful for scripts with multiple DDL or DML statements where visual separation helps readability.

Yes. The Preserve comments checkbox (enabled by default) keeps both line comments (--) and block comments (/* */) in the formatted output at their original positions. Unchecking it strips all comments for a clean output — useful when comments contain noise or version metadata.

Yes. Use Open .sql file to load a local .sql, .ddl, or .dml file. Processing is performed entirely in page memory. The client contains no fetch, XMLHttpRequest, navigator.sendBeacon, localStorage, or sessionStorage usage. Your SQL is never transmitted, persisted, or executed.

Formatting changes whitespace, indentation, and keyword casing for readability — it does not prove the SQL is syntactically correct for a specific database engine. SQL validation checks that the query parses correctly against a grammar. ToolsSonic's formatter reports lexical warnings (unclosed strings, unbalanced parentheses) but is not a full SQL parser or validator.

Linting checks semantic rules — for example, whether SELECT * is used, whether a JOIN condition exists, whether a DELETE has a WHERE clause. Formatting only changes layout. ToolsSonic focuses on formatting and lexical diagnostics; it does not apply linting rules or claim to catch query logic errors.

The review panel reports: unclosed single-quoted strings, unclosed double-quoted identifiers, unclosed backtick names, unclosed dollar-quoted strings, unclosed block comments, unbalanced parentheses, and empty-input warnings. The stats bar shows statement count, output lines, total tokens, recognized keywords, comments, maximum parenthesis depth, and warning count.

Yes. Select the PostgreSQL dialect hint. This adds RETURNING, ILIKE, MATERIALIZED, LATERAL, JSONB, SERIAL, BIGSERIAL, ARRAY_AGG, STRING_AGG, GENERATE_SERIES, and EXCLUDED to the recognized keyword set so they are formatted and recased correctly alongside standard SQL keywords.

Yes. Select the BigQuery dialect hint. This adds UNNEST, STRUCT, ARRAY_AGG, COUNTIF, APPROX_COUNT_DISTINCT, GENERATE_ARRAY, SAFE_CAST, TIMESTAMP_TRUNC, DATE_TRUNC, PIVOT, UNPIVOT, and other BigQuery-specific keywords to the recognized set.

Yes. Select the Snowflake dialect hint. This adds QUALIFY, SAMPLE, CLONE, UNDROP, FLATTEN, SPLIT_TO_TABLE, ARRAY_AGG, OBJECT_AGG, TO_VARIANT, PARSE_JSON, ARRAY_CONSTRUCT, OBJECT_CONSTRUCT, IFF, IFNULL, ZEROIFNULL, and other Snowflake-specific keywords. QUALIFY (used to filter window function results) and FLATTEN (used to expand semi-structured data) are formatted as major clause breaks for readability.

Yes. Select the Amazon Redshift dialect hint. This adds SORTKEY, DISTKEY, DISTSTYLE, ENCODE, COPY, UNLOAD, CONVERT_TIMEZONE, DATEADD, DATEDIFF, APPROXIMATE, PERCENTILE_CONT, MEDIAN, LISTAGG, REGEXP_COUNT, REGEXP_REPLACE, GETDATE, and other Redshift-specific keywords so they are formatted and recased correctly alongside standard SQL.

Yes. The formatter runs 8 heuristic lint checks on every format pass: (1) SELECT * is flagged as a readability hint, (2) DELETE without WHERE warns that all rows may be deleted, (3) UPDATE without WHERE warns that all rows may be updated, (4) DROP TABLE is flagged as a safety notice, (5) empty consecutive statements (;;) are reported, (6) CASE without a matching END is detected, (7) BEGIN without COMMIT or ROLLBACK is flagged for transaction boundary review, and (8) nesting depth ≥ 4 is flagged as a complexity hint. These are token-level checks — they add advisory messages to the review panel without blocking output or claiming full semantic validation.

Yes. Press Ctrl+Enter (or Cmd+Enter on Mac) to format at any time without clicking the Format SQL button. This shortcut works from both the input editor and anywhere else on the page.

Yes. Use Copy SQL to place the current output on the clipboard, or Download .sql to save it as a local SQL file. Neither action sends the query to a remote service. The download uses a browser Blob URL that is immediately revoked after the download starts.

Yes. The session history (last 8 formatted queries) is stored only in JavaScript memory for the current page session. It is never written to localStorage, sessionStorage, cookies, or a server. Refreshing the page clears it entirely.

Yes. All three cloud data warehouse dialects are supported with dedicated keyword sets. Snowflake SQL with QUALIFY, FLATTEN, ARRAY_CONSTRUCT, and semi-structured extensions is recognized. Amazon Redshift SQL with SORTKEY, DISTKEY, ENCODE, COPY, UNLOAD, and analytical function keywords is recognized. BigQuery SQL with UNNEST, STRUCT, PIVOT, UNPIVOT, ARRAY_AGG, and date-math functions is recognized. Select the appropriate dialect hint before formatting.