The SQL Validator Isn't a Real Parser — It Only Checks 3 Things
A tool called "SQL validator" sounds like it should verify a query with something close to the rigor of an actual database engine parsing SQL. But most lightweight, browser-based SQL validators don't understand SQL grammar at all. This guide opens the real code to see exactly what is and isn't checked, why that limitation exists, and why the tool is still useful anyway.
1. The key difference from a real SQL parser
A real SQL parser — inside a database engine, or a library like sqlparse — reads tokens in order and builds an abstract syntax tree (AST). In doing so, it also verifies grammar rules and clause ordering: whether a FROM clause correctly follows SELECT, whether WHERE comes before GROUP BY, and so on. If the order is wrong, the tree can't be built and the error surfaces immediately.
A lightweight validator that runs instantly in the browser, by contrast, never builds a tree. Since it sends nothing to a server and has to produce a result using only regexes and character-by-character scanning, it typically substitutes three much cheaper checks instead of tracking clause order with a state machine.
2. What the code actually checks
Reading the validate() function of the SQL Validator directly shows it does exactly three things.
- Matching parentheses: walks the string character by character, incrementing a counter on an opening parenthesis and decrementing on a closing one. If the counter isn't zero at the end, it's an error.
- Matching quotes: tracks, as state, whether a string started with a single or double quote was closed by the same character without an escape.
- Keyword presence: strips out the contents of string literals with a regex, then checks whether at least one of SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, WITH, CALL, or EXEC appears anywhere as a whole word.
If all three conditions pass, it's marked "valid" — nothing else is checked. Clause order, whether columns exist, whether tables exist, whether a JOIN condition makes sense — none of that is ever examined.
3. Experiment: does scrambling clause order really pass?
We fed the validator sentences where the keyword order makes no grammatical sense, to see how it would react. The result matched exactly what reading the code predicted.
| Input SQL | Parens | Quotes | Keyword present | Result |
|---|---|---|---|---|
FROM users SELECT * WHERE id=1 | none (OK) | none (OK) | SELECT found | ✓ Valid |
WHERE id=1 CREATE users FROM | none (OK) | none (OK) | CREATE found | ✓ Valid |
SELECT * FROM users ( | 1 unmatched | none | SELECT found | ✗ Error (parens) |
The first two lines are syntax errors no database would accept, but because the parentheses and quotes are balanced and at least one recognized keyword is present, the validator calls them "valid." That's a sharp contrast with the third line, which fails immediately over a single unmatched parenthesis. In other words, what this tool actually defends against is physical damage — parentheses or quotes getting cut off during copy-paste — not whether the query is a grammatically executable statement.
4. The same shallow approach causes a side effect in the formatter
The "Format" feature works the same way: it doesn't understand SQL structure and redraw it — it's a text substitution that finds a predefined list of keywords with a regex and uppercases them while inserting line breaks. So if a column name or alias happens to match a SQL keyword like key, order, or set, it gets uppercased regardless of context. A subtler problem lurks inside string literals. The validation function strips out single-quoted string contents with a regex before checking anything, but the format function applies its regex directly to the raw text with no such preprocessing. So something like WHERE status = 'select' can have the string value itself uppercased if it happens to match a keyword.
5. So when is it actually useful
Not verifying grammatical structure doesn't make this tool pointless. The errors that actually come up in practice tend to be far simpler than complex grammar mistakes — a parenthesis clipped off when copying SQL out of Slack or an email, or a quote left unclosed after pasting a multi-line string. These three checks catch that kind of physical damage just fine. What you shouldn't do is read a "valid" result as a guarantee that the query is executable. To actually confirm that, run it against a staging database, convert it to see the structure visually with the SQL to JSON Converter, or at minimum, clean up whitespace and comments with the SQL Minifier and review it by eye.
Frequently Asked Questions
Q. If it says "valid," is it safe to just run it?
A. No. Only three things are checked — parentheses, quotes, and keyword presence — so a query with clauses in the wrong order, or one referencing a column or table that doesn't exist, can still show as "valid." Whether it's actually executable needs to be confirmed separately.
Q. Why don't browser tools use a real parser?
A. A full SQL parser has to account for grammar differences across dialects (MySQL, PostgreSQL, Oracle, etc.), which makes it heavy to implement, and building it in pure JavaScript with no server also bloats the library size. A lightweight regex-based check is a practical tradeoff for load speed and implementation cost.
Q. Is it safe to ship the formatter's output as-is?
A. Since a column name matching a keyword, or a keyword-like word inside a string literal, can get changed unintentionally, it's a good idea to review the diff by eye after formatting before using it.
Q. Can this tool also catch SQL injection vulnerabilities?
A. No. This tool only checks whether a single string is grammatically undamaged, which is a different purpose from detecting injection patterns. Injection defense needs to be handled at the application level, e.g. with parameterized queries.