Sharon Ben-Moshe is the founder of sqlfmt, a browser-based SQL formatter and validator with misspelled-keyword suggestions across PostgreSQL, MySQL, SQLite, SQL Server, and BigQuery.
SELEC, FORM, WHER — SQL keyword typos produce confusing parser errors. Here are the most common SQL misspellings and the fastest ways to catch them.
Quick answer
SQL keyword typos like SELEC, FORM, and WHER cause parser errors that point to the wrong location — the parser treats the typo as an identifier and fails on the next token. Running SQL through a keyword spell-checker or SQL linter before execution catches these mistakes instantly, before they reach the database.
FORM (for FROM) is probably the most common SQL keyword typo, because it happens to be a real English word. The parser treats FORM as a table name, which shifts the error to a different token and makes the mistake much harder to spot on a quick read.
Why does "syntax error near" point to the wrong place?
SQL parsers report errors at the token they can't fit into the grammar, not the token that caused the confusion. A misspelled keyword is parsed as an identifier; the error fires when the next token doesn't match what the grammar expects after an identifier. The typo itself often appears one token before the location quoted in the error message.
Which SQL database gives the most helpful error message for keyword typos?
SQLite often names the mistyped token directly — "near 'WHER': syntax error" — which makes the typo easy to find. BigQuery is even more helpful, telling you what keyword it expected and what it received, along with the line and column number. PostgreSQL and MySQL typically point to the token after the typo rather than the typo itself.
How can I automatically catch SQL keyword typos in my workflow?
Run SQL through a keyword-aware spell-checker before executing it. A tool that validates syntax and keyword spelling can catch typos at the point of writing rather than at runtime. Adding SQL linting to a CI pipeline catches typos in migration files and seed scripts before they reach a staging or production database.
Are SQL keyword typos case-sensitive?
No — SQL keywords are case-insensitive, so SELECT, select, and SeLeCt all work. That's also why a keyword typo like SELEC isn't caught by case-sensitive validators: the typo and the correct keyword are both treated as case-insensitive tokens. A keyword spell-checker handles this by normalizing to uppercase and comparing against a known keyword list for the active dialect.
Fix Google BigQuery's "Unrecognized name: column" error. Learn alias visibility rules across WHERE and QUALIFY, case sensitivity, and struct unnesting.
Fix PostgreSQL Error 57014: canceling statement due to statement_timeout. Learn how to tune query plans, configure timeouts per session, and avoid lock waits.
A single mistyped keyword breaks a SQL query completely — and the error message rarely names the misspelled word. Instead, you get "syntax error at or near 'FORM'" and spend ten minutes staring at what looks like valid SQL.
Keyword typos are the silent culprits behind a surprising share of SQL parse failures. This post covers the typos developers make most often, what error messages look like across PostgreSQL, MySQL, SQLite, and BigQuery, and the fastest ways to catch them before they slow you down.
Why SQL Keyword Typos Produce Confusing Errors
SQL parsers are token-scanners. When the parser sees FORM, it treats it as an identifier — a table or alias name — not a misspelled FROM. The error then lands on the token after FORM, which looks perfectly valid. That's why "syntax error at or near 'users'" can actually be caused by FORM users.
FORM instead of FROM — a typo that moves the error
-- Typo: FORM instead of FROMSELECT id, nameFORM usersWHERE active = 1;-- PostgreSQL: ERROR: syntax error at or near "users"-- SQLite: near "users": syntax error-- MySQL: near 'users WHERE active = 1' at line 3
Fixed
SELECT id, nameFROM usersWHERE active = 1;
Case-insensitivity compounds the problem. SQL keywords work whether you type SELECT, select, or SeLeCt, which means editors don't always flag a misspelling the same way they would in a case-sensitive language. A syntax highlighter that colors FROM blue won't color FORM blue — that gap is exactly what a keyword spell-checker fills.
The Most Common SQL Keyword Typos
These are the typos that show up repeatedly in bug reports, Stack Overflow threads, and Slack channels. Every example below is real.
SELECT → SELEC, SLECT, SELEECT
SELECT is typed thousands of times a day, which makes its typos the most frequent. SELEC (missing the final T) is the most common variant, usually from lifting a finger too early. SLECT (transposed E and L) and SELEECT (double E from a stutter on the key) appear regularly too. Since SELEC is a valid identifier, the parser's confusion deepens — the error typically fires on the column name that follows, not the typo itself.
SELEC typo — error fires on the column list
-- Typo: SELEC instead of SELECTSELEC id, email, created_atFROM usersWHERE plan = 'pro';-- The parser sees SELEC as an identifier (table alias or function)-- then fails when it hits the comma after "id"
FROM → FORM, FRMO
FORM is one of the most treacherous SQL typos because it is a common English word. You can read a query three times and not notice it because your brain auto-corrects to "FROM". The parser, however, treats FORM as a table name, then complains about the actual table name that follows. FRMO (transposed M and O) is less common but produces the same misdirected error.
WHERE → WHER, WEHRE, WHEER
WHERE typos typically drop the final E (WHER) or swap two adjacent letters (WEHRE). Both produce the same outcome: the parser sees a valid identifier, then fails when it hits the column name that follows. This is particularly confusing when the error message says "syntax error at or near 'active'" for a query where active is a perfectly valid filter column.
WHER typo — error fires on the column name
-- Typo: WHER instead of WHERESELECT order_id, totalFROM ordersWHER status = 'pending';-- PostgreSQL: syntax error at or near "status"-- SQLite: near "WHER": syntax error (names the typo directly!)-- BigQuery: Syntax error: Expected end of input but got identifier WHER
JOIN → JION, JOIM
JION (transposed I and O) is the canonical JOIN typo. It's common enough that it appears in the error-log hall of fame on nearly every SQL-heavy team. The fix is instant once you spot it, but finding it takes time in a long FROM clause with several joins. JOIM (N hit as M on an adjacent key) is less common but appears on keyboards with worn keycaps.
GROUP BY → GRUOP BY, ORDER BY → ORDR BY
Multi-word keywords offer more surface area for mistakes. GRUOP BY (swapped R and U in GROUP) is the most common aggregate-clause typo. ORDER BY has analogous variants: ORDR BY and ODER BY appear in real production queries. Occasionally developers type GROUP B and omit the Y entirely, which produces a different grammar error but is equally confusing.
GRUOP BY typo
-- Typo: GRUOP BY instead of GROUP BYSELECT department, COUNT(*) AS headcountFROM employeesGRUOP BY departmentORDER BY headcount DESC;-- Error: syntax error at or near "department" (the column after GRUOP)
CREATE TABLE → CRATE TABLE, CREATE TABEL
DDL keyword typos are worth calling out separately because the stakes are higher. A broken SELECT just returns an error. A broken migration script can stall a deployment. CRATE TABLE (missing E in CREATE) and CREATE TABEL (E and L swapped in TABLE) are the most common DDL typos. The same logic applies to ALTER TABLE and DROP TABLE — linting DDL in CI is especially worthwhile.
What the Error Message Looks Like Across Dialects
The same typo produces a different error message in each database engine. Knowing the pattern for your database helps you trace the problem back to its source immediately.
PostgreSQL
PostgreSQL names the unexpected token, not the typo: ERROR: syntax error at or near "users" when FORM users appears. The actual misspelled word usually appears in the context line directly below, but it takes practice to read that far. See our guide to fixing PostgreSQL syntax errors for a full breakdown, and the PostgreSQL lexical structure docs to understand how the parser categorizes identifiers versus keywords.
MySQL
MySQL error 1064 shows the string starting just after where the parser stopped: near 'users WHERE active = 1' at line 3. The misspelled keyword sits one or two tokens before the quoted snippet. Our guide to MySQL error 1064 walks through the seven most common causes and fixes.
SQLite
SQLite gives the most useful error message for keyword typos: near "WHER": syntax error. It quotes the mistyped token directly, which means the error often names the problem explicitly. The SQLite language reference lists every reserved keyword — useful when you're unsure whether a word is a keyword or a valid identifier in SQLite.
BigQuery
BigQuery is the most informative: Syntax error: Expected keyword FROM but got identifier FORM at [2:1]. It tells you what it expected, what it received, and the exact line and column. Even so, you need to connect "got identifier FORM" with "I typed FROM wrong" — the message doesn't say "typo". The BigQuery lexical reference documents the full set of reserved keywords and operators for Standard SQL.
How to Catch SQL Keyword Typos Before They Reach the Database
Run SQL through a keyword spell-checker. A tool that checks every keyword against a per-dialect dictionary and surfaces "Did you mean GROUP BY? (GRUOP BY)" catches the mistake at the point of writing. sqlfmt's typo checker uses optimal-string-alignment distance to rank suggestions so that common transpositions like SELEC → SELECT rank ahead of less likely corrections.
Use a SQL-aware editor. VS Code with a SQL extension, DataGrip, and DBeaver all highlight unrecognized keywords in real time. If WHER doesn't turn the same color as WHERE, that's a visual signal something is wrong. This catches typos before you run the query.
Add SQL linting to CI. Tools that validate SQL as part of your build pipeline catch keyword typos in migration files and seed scripts before they reach a staging or production database. See our SQL formatting best practices guide for what else to include in a SQL quality gate.
Read the error message one token to the left. Most parser errors quote the token where parsing failed, not the typo itself. Train yourself to look at the token immediately before the quoted fragment. If the error says "near 'status'", the typo is almost certainly the word that appears just before status in your query.
Format your SQL before reviewing it. Consistent indentation and keyword casing make typos stand out visually. When all keywords are uppercase, FORM jumps out next to SELECT and WHERE because your eye pattern-matches familiar shapes. A formatter that normalizes casing makes this review faster.
Wrapping Up
SQL keyword typos — FORM, SELEC, WHER, GRUOP BY — produce errors that point somewhere other than the problem. The practical fix is two-part: understand that the error usually fires one token after the typo, and catch the mistake before execution using a keyword-aware tool rather than relying on error-message archaeology.
sqlfmt formats your SQL and runs a keyword spell-check at the same time, surfacing typo suggestions alongside syntax errors so you fix both before you run anything.