Tool · Validate

SQL Validator

Check whether a query parses as valid SQL for a specific dialect. Pick your dialect, paste the query, and it’s validated as you type — a valid query is formatted for you, and a syntax error is pinpointed to the line and column. It’s a syntax check, not a database connection, so it never runs your query or touches your data.

Valid PostgreSQL

input

PostgreSQL — valid

SELECT
  id,
  name
FROM
  users
WHERE
  created_at > now()
ORDER BY
  name

Invalid vs. valid

An unclosed parenthesis is the classic case. On the left the parser reaches the end of the query still waiting for a ); on the right the bracket is closed, and the same query parses and comes back formatted.

invalid

SELECT id, name
FROM users
WHERE id IN (
  SELECT user_id FROM orders
ORDER BY name

valid PostgreSQL

SELECT
  id,
  name
FROM users
WHERE id IN (
    SELECT user_id
    FROM orders
  )
ORDER BY name;

Errors the validator catches

Your SQL is parsed against the grammar of the dialect you selected — the same parser the formatter uses. These are the mistakes that reliably fail the parse, each reported with the line and column of the token that broke it.

Unclosed parenthesis

SELECT * FROM t WHERE id IN (SELECT user_id FROM orders

The most common structural break. The error points at the end of input, because that's where the parser ran out of query still waiting for a ')'.

Unbalanced closing parenthesis

SELECT * FROM t WHERE (a = 1))

Reported at the extra ')' itself — column 30 here.

Unterminated string literal

SELECT * FROM t WHERE c = 'US

A quote inside a literal has to be doubled: 'O''Brien', not 'O'Brien'.

Unterminated quoted identifier

SELECT "col FROM t

The parser swallows the rest of the line into the identifier and fails at the end of it.

Unmatched CASE without END

SELECT CASE WHEN a THEN 1 FROM t

Block structure is checked: CASE needs its END before the clause can close.

Quoting from the wrong dialect

SELECT `col` FROM t

Backticks are MySQL and BigQuery. In PostgreSQL the same query fails — switch the dialect and it parses.

What it won’t catch

Worth knowing before you treat a green badge as a guarantee. The parser is lenient in a few places, so some SQL that your database will reject still passes here.

Trailing comma before FROM

SELECT id, name, FROM users

Parses here, rejected by the database. The parser is lenient about list separators, so this one it won't flag.

Missing comma between columns

SELECT id name FROM users

Valid SQL with a different meaning: name becomes an alias for id. No parser can call this an error.

Keyword from another dialect

SELECT TOP 10 * FROM users

TOP is T-SQL; PostgreSQL wants LIMIT 10 and Oracle FETCH FIRST 10 ROWS ONLY — but the parse still succeeds. Quoting style is dialect-checked, keyword-level differences aren't.

Unquoted reserved word

SELECT order, user FROM t

Your database will reject order as a column name. Quote it per dialect: "order" in PostgreSQL, `order` in MySQL, [order] in T-SQL.

Misspelled keyword

SELCT * FRM users

Read as identifiers rather than keywords, so it parses. A quick look at the formatted output gives it away — nothing is highlighted as a keyword.

And anything that needs a database

Tables and columns

The validator has no connection to your database, so it can't know whether users.email exists. A typo'd column name is valid SQL.

Types and semantics

Comparing a date to an integer parses fine and fails only at execution time.

Permissions and runtime errors

Missing grants, deadlocks and constraint violations all happen after parsing.

Frequently asked questions

Is the SQL validator free?

Yes. It's free, needs no account and has no usage limit. Validation runs entirely in your browser.

Is my SQL uploaded anywhere?

No. The query is parsed client-side by the same engine the formatter uses. Nothing leaves your machine and nothing is stored.

Which dialects can it validate?

PostgreSQL, MySQL / MariaDB, T-SQL (SQL Server), SQLite, BigQuery, Oracle (PL/SQL), Snowflake and Redshift — pick the dialect above the input box.

Does it check that my tables and columns exist?

No. It's a syntax check, not a database connection, so it validates grammar only. Names, types and permissions are checked by your database at execution time.

Does a valid result guarantee the query will run?

No. The parser is deliberately lenient in places — a trailing comma before FROM or a keyword borrowed from another dialect can still parse here and be rejected by your database. It reliably catches structural errors: unbalanced parentheses, unterminated literals and unmatched CASE blocks.

Can it validate several statements at once?

Yes — separate them with semicolons and each one is parsed in turn. The first statement that fails is where the error is reported.

Next steps

Once a query parses, format it to read it, or run it through the SQL minifier to squeeze it back onto one line for a config value or a log. Minified SQL that stopped working is worth pasting back in here first — a swallowed comment or a broken literal shows up as a parse error immediately.

More SQL tools

Read an EXPLAIN plan Optimize a SQL query Convert between dialects SQL minifier