SQL Linter
Free online SQL linter — paste any query and get instant feedback on anti-patterns and style issues: SELECT *, UPDATE/DELETE without WHERE, implicit comma JOINs, trailing commas, leading-wildcard LIKE, double-quoted strings, keyword casing, and possible N+1 query loops. Every finding shows a severity, line number, and a concrete fix. 100% client-side — your SQL never leaves your browser.
Lint your SQL
Try a worked example:
Rules checked
Eleven heuristic rules across four severity levels. String literals and comments are masked before analysis, so a SELECT * inside a string is never flagged.
| Rule | Severity | What it detects |
|---|---|---|
select-star | Warning | SELECT * or t.* in the select list (COUNT(*) and arithmetic * are ignored) |
missing-where | Danger | UPDATE or DELETE with no WHERE — rewrites every row |
where-tautology | Warning | WHERE 1=1 — a filter that filters nothing |
trailing-comma | Error | Comma before FROM, ) or ; — a real syntax error |
implicit-join | Warning | FROM a, b comma join — use explicit JOIN … ON |
join-without-on | Warning | JOIN with no ON/USING — accidental cartesian product |
like-leading-wildcard | Warning | LIKE '%…' — B-tree indexes cannot be used |
string-style | Info | Double-quoted string literal — standard SQL reserves "…" for identifiers |
keyword-case | Info | Inconsistent or all-lowercase keyword casing |
missing-semicolon | Info | Statement not terminated with ; |
n-plus-one | Info | 3+ structurally identical SELECTs — probable query-in-a-loop |
Honest framing: this is heuristic linting, not a full SQL parser. It catches the most common and costly mistakes instantly, in your browser, with zero setup. For dialect-exact parsing (e.g. in CI), pair it with a real parser such as sqlfluff.
How the SQL linter works
- Mask. String literals (
'…',"…"), quoted identifiers, and--//*…*/comments are blanked out first — preserving positions — so rules never fire on text inside them. - Split. The masked SQL is split into statements on top-level semicolons (a
;inside a string is ignored thanks to masking). - Scan. Each of the 11 checks runs over the masked statements: star detection walks the select list at paren-depth 0, write statements are tested for
WHERE, JOINs are tested forON/USING, and SELECT fingerprints are compared to spot N+1 loops. - Score. Findings are sorted by position and rolled into a 0–100 lint score (danger −25, error −15, warning −10, info −3), with per-severity counts and line:col locations.
Frequently asked questions
What does this SQL linter check?
Eleven heuristic rules: SELECT * usage, UPDATE or DELETE without WHERE, WHERE 1=1 tautologies, trailing commas, implicit comma JOINs, JOIN without ON/USING, leading-wildcard LIKE patterns, double-quoted string literals, inconsistent keyword casing, missing semicolons, and repeated near-identical SELECTs (N+1 hint). Each finding carries a severity, line number, and a concrete fix suggestion.
Is this a real SQL parser like sqlfluff?
No — and that is stated openly. This tool uses fast heuristic pattern matching (regular expressions over comment- and string-aware masked text), not a full SQL grammar parser like sqlfluff. That makes it instant and dependency-free in the browser, but it cannot prove a query is syntactically valid. For CI-grade dialect parsing, use sqlfluff or your database's own parser.
Does the linter execute my SQL?
Never. It performs static analysis only: it reads the text of your query and matches patterns against it. Nothing is sent to a database, nothing runs, and nothing leaves your browser — all analysis happens locally in JavaScript.
Which SQL dialects are supported?
The rules are written against generic ANSI SQL so they apply to PostgreSQL, MySQL/MariaDB, SQLite, SQL Server (T-SQL), and Oracle. A few notes are dialect-aware: double-quoted string warnings matter most on PostgreSQL/Oracle, and bracket [identifiers] are recognized as T-SQL quoting. There is no per-dialect grammar switching.
Is SELECT * always bad?
Not always — it is fine in ad-hoc exploration, COUNT(*) is perfectly fine, and this linter never flags those. It is risky in production code because schema changes silently change the result shape, extra columns waste I/O and memory, and ORMs can break. Treat the warning as "list your columns explicitly in shipped code".
What do the severity levels mean?
Danger: the statement could destroy or rewrite data (UPDATE/DELETE without WHERE). Error: the SQL will not run at all (trailing comma). Warning: it runs but is likely slow or wrong (cartesian JOIN, leading-wildcard LIKE, implicit join, SELECT *). Info: style and maintainability notes (keyword casing, semicolons, quote style, N+1 hint).
Can it catch every syntax error?
No. Heuristic linting catches common, high-value mistakes but a misspelled keyword, a wrong column name, or a type mismatch will pass silently. Think of it as a spell-checker for SQL style and anti-patterns, not a compiler. Run the query against a real database (or sqlfluff with your dialect) for full validation.
Is my SQL sent to any server?
No. This page is 100% client-side: the linting engine is JavaScript running in your own browser tab. Your queries never leave your device, there is no account, and nothing is logged.
Related tools: SQL Query Formatter (beautify and uppercase messy SQL) · SQL to JSON (convert query results) · SQL Escape (escape strings for safe embedding) · SQL to CSV (export result sets as CSV).
Free tool by NRTechStudio