SQL Syntax Validator

Runtime is a terrible place to learn about a syntax error. The migration window opens at 2 a.m., the script has been reviewed twice, and the database's answer to your 400-line ALTER sequence is a laconic `ERROR: syntax error at or near "FROM"` with a position number and nothing else. You count characters in the dark, discover the trailing comma, and resolve to never again run SQL that has not been checked by something whose only job is checking.

This page is that something. Paste a query or an entire migration script, pick a dialect — or let the tool guess it — and get a verdict in milliseconds: valid, or invalid with the exact line, column, and offending token. It parses; it never executes. There is no database behind it, which is precisely why it can sit between you and the 2 a.m. window without asking for a connection string first.

The syntax-check niche has been quietly underserved forever: formatter sites will happily reformat your SQL and silently fail on the broken parts, and 'paste it into a scratch database' is advice that assumes you have a scratch database, credentials, and patience. A validator page that reports exact error positions for three major dialects, offline, fills the actual gap.

Two kinds of correctness matter for SQL, and conflating them causes most of the confusion in this corner of the internet. Syntactic correctness asks: does this text parse under the dialect's grammar — balanced parentheses, clauses in the right places, no keywords where expressions belong? Semantic correctness asks: do these tables and columns exist, are the types compatible, will this query actually run against my schema? The first question is answerable from text alone. The second requires a live database or at least a schema dump.

This validator answers the first question, completely and offline. That division of labor is not a limitation so much as a boundary with useful properties: no connection means no credentials to manage, no risk of accidentally running the DELETE you meant to lint, and no possibility that checking a query disturbs anything. Semantic checks belong to your database's own tooling — it is the only party that knows the truth.

In practice, syntax is also where most late-caught errors live. Trailing commas before a closing parenthesis, unbalanced quotes, an alias that happens to be a reserved word, backticks in a Postgres script — every one of these is a full runtime failure that a parse would have caught in milliseconds. The validator catches the class of error that is embarrassing precisely because it was always checkable.

1. 1

   Paste your SQL

   A single statement or a semicolon-separated script. Comments in all the usual styles survive and are attributed to the right statement.

2. 2

   Confirm the dialect

   Auto-detect scores MySQL, PostgreSQL, and SQLite fingerprints in your text and proposes the strongest match; override if you know better. Dialect matters — the same text can be valid MySQL and invalid Postgres.

3. 3

   Read the verdict

   Valid means every statement parsed under the chosen grammar. Invalid lists each error with statement number, line, column, the offending token, and a one-line explanation of what the grammar expected at that point.

4. 4

   Fix and re-check

   The validator re-parses on every keystroke, so the error list updates as you edit. When it goes quiet, your syntax is clean in that dialect — semantic questions are then a matter for the database.

Four steps, no account, no connection, and no file to install. The tool is deliberately boring in the way good infrastructure is boring.

Under the hood is the same two-stage machinery every compiler uses, sized for SQL. The lexer first turns your text into tokens: keywords, identifiers, string and numeric literals, operators, comments. It tracks line and column for every token it emits, which is where exact error positions come from — the parser consumes tokens, and when the grammar rejects one, the position attached to that token is the position reported to you.

The parser then walks the token stream against the dialect's grammar. SQL grammars are mostly predictable — a SELECT is a column list, then FROM, then an optional WHERE expression tree, and so on — so a parser failure localizes cleanly: the first token that cannot extend a valid production is the error. What the tool adds on top of the raw parse is error translation, converting `expected expression, found keyword 'FROM'` into the sentence a human wants: *there is a trailing comma before FROM, or a missing column name.*

tokenize(text)  ->  [ {kind, value, line, col}, ... ]
parse(tokens, dialect)  ->  AST | Error{token, expected}

on Error:
  statement index  = count of ';' before error token
  line / column    = token position
  hint             = rule table lookup(token.kind, expected)

Dialect auto-detection runs before parsing as a scoring pass over the token stream. Backticks vote MySQL; double-quoted aliases vote Postgres; `AUTOINCREMENT` as one word votes SQLite; `LIMIT n` is neutral territory while `TOP n` votes T-SQL; `::` casts are a Postgres landslide. No single signal is conclusive, so the detector sums the evidence and shows you the tally — you are overruling an informed guess, not a coin flip.

Multi-statement scripts get the same treatment with a bit more bookkeeping: the input is split on semicolons at the token level — never inside string literals or comments — and each statement is parsed and scored independently. The error list therefore reads like a build log: statement 7 fails at line 89, statement 12 fails at line 140, everything else green. That granularity matters for migrations, where you want to know whether the script is salvageable with two edits or fundamentally wrong, before the change window opens and answers the question for you.

One subtlety in the design worth knowing: the validator reports the first grammar-breaking token, not every downstream consequence. A missing closing parenthesis at line 3 can surface as an unexpected end-of-input at line 40, because the parser was legitimately inside a subexpression the whole way down. The tool handles the common case — tracking back to the unmatched opener — because it maintains a parenthesis stack during the walk, which is also how you get 'opened at line 3, column 18' as part of the message instead of a shrug.

Every error class below appears constantly in the wild — each one is a runtime failure that costs minutes to hours, and each one is caught here in the time it takes to paste:

SELECT name, FROM users;

SELECT id FROM users WHERE (role = 'admin' AND active = 1;

SELECT `id`, `name` FROM users;

SELECT total order FROM invoices;

The fourth case deserves special affection, because it is the one engines report worst: several databases will accept `order` as an alias in some contexts and reject it in others, making the bug intermittent by construction. A grammar check applied uniformly catches it every time, which is what grammar checks are for.

Count the character columns yourself on the first example — `SELECT name, ` is thirteen characters, so FROM begins at column 14, exactly where the error points. That precision is not a nicety; it is the difference between an error report you act on and an error report you re-derive.

Most 'invalid SQL' turns out to be valid SQL in the wrong accent. The table below is the compatibility cheat sheet the validator effectively enforces — the places where the major dialects disagree on spelling:

Paste a query containing backticks with the dialect set to PostgreSQL and the validator flags the backtick; switch the dialect to MySQL and the same text passes. That asymmetry is the point of dialect-aware validation rather than lowest-common-denominator checking — the tool models how each database actually reads your text, not an average of them that matches none.

The matrix is also a migration checklist. Moving a report from MySQL to Postgres means auditing every row of that table in your query text; the validator automates exactly this audit, one parse at a time, and its error list is effectively the diff between your SQL and the destination dialect's expectations.

The upsert row earns its place at the bottom of that table as the most-migrated feature in practice, because the three spellings are not stylistic variants — they encode genuinely different conflict-resolution models. MySQL's ON DUPLICATE KEY UPDATE fires on any unique-key collision; Postgres and SQLite's ON CONFLICT let you name the exact constraint in conflict; T-SQL's MERGE has semantics of its own and a documented list of caveats longer than the syntax. When a converted script validates but behaves differently in production, this row is usually the reason — the grammar agreed, the meaning did not.

A passing grade from this tool has a specific scope, and overselling it would get someone hurt:

• No schema awareness. `SELECT color FROM users` validates even if users has no color column. Column and table existence are semantic facts; only your database knows them.
• No type checking. Comparing a string to an integer in a WHERE clause parses fine everywhere and means something different in each engine.
• No permission modeling. A query can be valid for the dialect and still fail at runtime for grants, locks, timeouts, or resource limits.
• False negatives on exotic syntax. Vendor extensions outside the parser's grammar — certain JSONB operators, procedural blocks, some ANALYZE and VACUUM spellings — can be rejected despite being legal. When the validator disagrees with a database that accepted the query, the database wins.
• No logic review. A perfectly parsed DELETE without a WHERE clause is a perfectly parsed catastrophe. The validator checks grammar, not judgment.

Stating the boundary this plainly is also what keeps the tool honest — a validator that implies more knowledge than it has is worse than no validator, because its verdicts start substituting for thinking instead of accelerating it.

The heaviest users are people touching production migrations. A script with thirty ALTER statements gets pasted here before the change window opens, because the cost of a mid-migration syntax error is not the error — it is the partially-applied script in front of it. Statement-level error positions let the fix happen before anything runs at all.

The second cohort is the SQL-in-code crowd: query builders, ORM-generated SQL captured from logs, embedded analytics queries in application code. Pasting the generated text into a validator is the fastest way to see what the framework actually emitted, and dialect pinning catches the classic failure where an ORM targets Postgres in development and the production warehouse speaks a different flavor.

Students and interview-preparers round it out — a syntax checker is instant feedback while drilling, with no database to install and no environment to break. And there is a persistent, honorable population pasting SQL copied from documentation or a forum post, checking which dialect it actually belongs to before adapting it. The auto-detector answers that question in one glance, which is a nicer experience than the traditional method: running it and reading the error.

Around this tool sits the rest of the loop: the SQL Query Explainer narrates what a validated query does clause by clause, SQL on CSV runs real SQL against flat files with no server, and the JSON Formatter & Validator and YAML Validator apply the same check-before-you-run discipline to the config formats that travel with database code.

The scratch database is the traditional answer and it works, but it is heavyweight for the question being asked: standing up a container to catch a trailing comma is using a live database as a spell checker. Formatter sites are the accidental answer — people paste broken SQL into pretty-printers, the formatter produces garbage or nothing, and the user learns less than they came with. The dedicated-validator row exists because the question deserves a tool shaped like the question.

The AI row is included with respect and one caveat: probabilistic checkers can be genuinely helpful for explanation, but their verdicts on syntax arrive with unearned confidence, including inventing rules that do not exist in any dialect. When the answer needs to be exact — and syntax is nothing if not exact — a parser with a grammar is the right instrument.

The validator ships its grammar to your browser and does all its work there. Lexing, parsing, error translation, dialect scoring — every stage runs in the tab, and the page makes no request after load. Your SQL, which in production form contains table names, literal filters, and occasionally a customer ID somebody pasted into a WHERE clause in 2019, stays exactly where it already was.

The offline property is a direct consequence of doing parsing instead of execution. A tool that needs to run queries needs a database somewhere; a tool that needs only a grammar needs nothing but the page itself. That is why this can work on a plane, inside a customer's network with no outbound access, and on machines where installing a scratch database is a four-week procurement conversation.

There is also a quiet speed argument: no network round-trip means validation latency is parser latency, single-digit milliseconds even for long scripts. The error list updates as you type, which changes the editing rhythm from paste-pray-fix to something closer to a spell checker's red squiggle — immediate, ignorable when clean, pointed when not.

The neighbors: the query explainer narrates what a clean query actually does, SQL on CSV executes it against files with no server, and the JSON Formatter & Validator plus YAML Validator apply the same check-before-you-run discipline to the config formats that ship alongside database code.