SQL Formatter & Validator Pro
Format, validate, and optimize SQL with enterprise-grade precision and multi-dialect support
SQL Input
Formatted Output
Formatted Output
SQL Formatter & Validator Pro
Format, validate, and optimize SQL with enterprise-grade precision and multi-dialect support
Features
- Multi-dialect SQL support (MySQL, PostgreSQL, SQL Server, Oracle, SQLite, BigQuery, Snowflake) — chooses keyword set, quoting style, and reserved-word rules per dialect
- Three keyword cases: UPPER (the SQL convention), lower (some codebases prefer), Capitalize (rare but supported) — pick the style your team uses
- Smart indentation: aligns SELECT columns, ON/JOIN conditions, CASE/WHEN branches, and CTE definitions; preserves comments at their original lines
- Validation pass: unmatched quotes (single and double), unclosed CASE statements, suspicious patterns (SELECT *), with line/column references for each finding
- Statistics panel: lines, characters, keyword count, JOIN count, subquery depth — useful for query-complexity reviews and refactor planning
- Minify mode for embedding SQL in JSON/code: collapses whitespace while preserving string literals, comments, and identifier quoting
- Preserve-comments toggle: keep -- single-line and /* */ multi-line comments through formatting (default on; turn off to strip documentation when minifying)
- Pure client-side: tokenization and formatting run in your browser, no upload. Safe for queries containing PII column names or proprietary table schemas
How to use
- Paste your SQL into the input pane.
- Pick the dialect matching your target database (MySQL, PostgreSQL, etc.). Default works for most generic SQL.
- Choose keyword case (UPPER convention or lower if your style guide says so) and indent size.
- Click Format. The result shows formatted SQL alongside any validation warnings (unmatched quotes, SELECT *, etc.).
- Toggle to Minify mode for collapsed output suitable for JSON embedding or single-line logging.
- Copy or download the result.
Tips & Best Practices
- Standardize SQL style across your team: pick keyword UPPER + 2-space indent + dialect=your-DB and put the format command in pre-commit.
- Run formatted SQL through your DB's EXPLAIN ANALYZE before deployment; the formatter doesn't catch performance issues (Cartesian joins, missing indexes).
- For multi-statement scripts, format each statement separately; some dialects choke on combined output.
- Use minify mode for SQL embedded in test fixtures (JSON) to keep the fixture readable while preserving the query.
- For complex CTE / window function code, beautify mode's line-up of ON conditions makes review much easier.
FAQ
How does the dialect setting affect formatting?
Dialect chooses the reserved-keyword set (PostgreSQL knows RETURNING, MySQL doesn't; SQL Server knows IDENTITY, others don't), the identifier quote style (PostgreSQL uses ", MySQL uses `, SQL Server uses []), and dialect-specific syntax (UPSERT, MERGE, OVER PARTITION BY). The formatter applies the right indentation per dialect.
Why does the validator flag SELECT *?
SELECT * fetches every column — bad for production for several reasons: schema changes silently add columns to your query result; the optimizer can't use covering indexes; network bandwidth includes columns you don't use. The validator flags it as a soft warning; if you intentionally use it (debugging, exploring), ignore.
Can it format dialect-specific syntax like PostgreSQL's WITH RECURSIVE?
Yes. Pick PostgreSQL dialect and the formatter knows WITH RECURSIVE, RETURNING, ILIKE, ::cast, JSON operators (->, ->>, #>), and other PG-isms. Same for MySQL's LIMIT … OFFSET, SQL Server's OFFSET … FETCH, BigQuery's WITH TIMEZONE, etc.
How are comments preserved?
Single-line comments (--) stay on their original line. Multi-line (/* */) preserve internal whitespace and indent level. If a comment runs into a new statement after formatting, the formatter keeps it bound to its original location.
Why does my query break after minify?
It shouldn't — minify collapses whitespace while respecting string and comment boundaries. If a literal contained a newline (multiline string), it's preserved. If you see breakage, the query likely had a syntax issue the formatter didn't catch; validate via your DB's parser.
What does the keyword-case option do for table/column names?
Keyword case only affects SQL keywords (SELECT, FROM, WHERE, JOIN, etc.), not identifiers. Your table names stay case-preserved (most DBs are case-sensitive for quoted identifiers and case-insensitive for unquoted; the formatter doesn't change them).
Is my SQL sent anywhere?
No. Tokenization and formatting run in your browser. Safe to paste queries containing real production data, table names, or column references.
Can I configure custom indent rules per project?
The tool exposes the common options (indent size, keyword case, line wrap). For project-specific rules (subquery indentation depth, CTE alignment, MERGE/ON conflict style), consider integrating sql-formatter into your CI and configuring it via .sql-formatter.json.