SQL Validator: check SQL syntax online for MySQL, PostgreSQL, MariaDB and SQLite
SQL
Result
Paste a query to check its syntax.
What does a SQL validator do?
A SQL validator reads your query the way a database would and tells you whether it is well-formed, before you run it against anything. Paste a query and it either confirms the syntax is valid or points at the exact line and column where it stops making sense.
That is quicker than the usual loop of running a query, waiting for the database to reject it, and decoding an error message written for the engine rather than for you, and it costs nothing, because the query is never executed.
Why use it?
- Find the typo faster. A misplaced comma or a missing keyword can be hard to see in a long query. The caret marks the character the parser choked on.
- Check before you run. Useful when the query is destructive, expensive, or bound for a database you would rather not hammer with broken statements.
- Learn the grammar. The error lists what the parser expected at that point, which is often the fastest way to understand why a clause has to come where it does.
Example
FORM instead of FROM. Reported at line 2, with the alternatives the parser was expecting:
SELECT id, name
FORM users
WHERE id > 10;SELECT id, name
FROM users
WHERE id > 10;What it checks, and what it does not
This is a syntax checker. It knows the grammar of the dialect you pick, and nothing about your database. So it will catch a malformed JOIN, an unclosed bracket or a keyword in the wrong place, but it cannot tell you that a table does not exist, that a column is misspelled, or that you are comparing a date to a string, because it has never seen your schema.
A query that passes here can still fail against your database. That is not a bug in the checker; it is the boundary of what any tool can know without a connection to your data.
Supported dialects
Four, and the choice matters: a query written for one database is frequently invalid in another, so checking Postgres syntax as MySQL will report errors that are not there.
| Option | What it controls | Possible values |
|---|---|---|
| Dialect | Which grammar your query is checked against | MySQL, PostgreSQL, MariaDB, SQLite |
The SQL Formatter next door supports eight dialects, because laying a query out needs less understanding of it than parsing it does. If your database is not in the list above, the formatter can still tidy the query. It just will not vouch for it.
How to use it
- Pick the dialect your database speaks.
- Paste your SQL into the left panel. It is checked as you type. There is nothing to click.
- If there is an error, the right panel names the line and column and underlines it in the editor. Click the error to jump straight to it.
Frequently asked questions
Is my SQL sent to a server?
No. The check runs entirely in your browser: the query is never uploaded, stored or logged, and it is never executed against any database. The page keeps working if you go offline after it loads.
Does a valid result mean my query will run?
It means the syntax is well-formed for the dialect you picked. It does not mean the query will succeed: the checker has never seen your schema, so it cannot know whether a table or column exists, or whether the types line up. A query can be perfectly valid SQL and still fail against your database.
Which dialects can it check?
MySQL, PostgreSQL, MariaDB and SQLite. Picking the right one matters: SQL written for one database is often invalid in another, so checking a Postgres query as MySQL will report errors that do not exist.
Why does it only report one error at a time?
The parser stops at the first thing it cannot read, because everything after that point depends on how the first problem is resolved. Listing further errors would mean guessing what you meant. Fix the one it names and re-check; the next one, if any, appears immediately.
The error points at the word after my mistake. Why?
A parser only knows something is wrong once it reaches a token that cannot follow what came before. Misspell FROM as FORM and it reads FORM as a column alias, then trips on the table name after it. The list of expected keywords in the message usually points straight back at the real mistake.
What is the difference between this and the SQL Formatter?
The formatter lays a query out and does not judge it: SELECT * FORM users formats quite happily. The validator parses it properly and tells you it is wrong. Use the formatter to make a query readable, and the validator to find out why it will not run.