How to Fix "ReferenceError: x is not defined"

ReferenceError: x is not defined is JavaScript being blunt with you: it tried to resolve the name x, walked the entire scope chain from where you used it out to the global object, and came up with nothing. There is no variable, no function, no import, no global by that name in reach. The engine cannot even guess what you meant, so it stops.

That is genuinely useful information, because it narrows the problem to one question — why can this name not be found here? — and there are only a handful of answers. This guide walks each of them, with a broken snippet and the fix beside it.

This is the distinction that trips people up, so it is worth nailing down before the fixes. Both errors show up red in the same console, but they point at opposite problems:

• ReferenceError — the name is missing. usrname was never declared, so there is nothing to read. JavaScript never even gets to a value.
• TypeError — the name is fine, but the value is unusable. user.name where user is undefined, or calling something that is not a function. The lookup succeeded; what came back was wrong.

If you are staring at "cannot read properties of undefined" or "x is not a function," you are in TypeError territory and those guides are the right stop. If the message ends in is not defined, stay here.

Almost every ReferenceError is one of the following. Read the name in the message first — it is the single most important clue — then match it to the pattern below.

The most common cause is also the most boring: the name in the message is not spelled the way you declared it. Case matters, and so does every letter.

When the message names something you are sure you declared, compare the two spellings character by character — username vs userName, fetchdata vs fetchData. An editor with rename-symbol refactoring and a linter's no-undef rule catch most of these before you ever run the code.

This is the case that surprises people who learned that declarations are "hoisted." They are — but let and const hoist differently from var, and the difference is a whole class of ReferenceError.

Here is what is actually happening. Both let and var bindings are hoisted to the top of their scope, so in a sense the name count exists from the first line of the block. The difference is initialization. A var is initialized to undefined immediately, so reading it early gives you undefined rather than an error. A let or const binding is not initialized until its declaration line executes. The window between the top of the block and that line is the temporal dead zone (TDZ): the name is reserved, but touching it throws Cannot access 'count' before initialization — a ReferenceError.

The TDZ exists on purpose. It turns a silent undefined bug into a loud, immediate error, which is almost always what you want. The fix is never to switch back to var; it is to move the declaration above the first use, which is where it belonged anyway.

A variable declared with let or const is scoped to the nearest block — the braces of an if, a loop, or a function. Try to read it from outside those braces and it is genuinely not defined there, even though it was moments ago on a nested line.

The same shape shows up across function and module boundaries: a helper reaches for a variable that was local to a different function, or a module uses a name that was never exported from — or imported into — it. If the name is defined somewhere but not here, the fix is to widen the declaration to a shared scope, pass it in as an argument, or export and import it explicitly.

When the missing name is a function or class from another file or a library, the cause is usually a forgotten import or a script that has not loaded yet. In a module system the fix is one line; with plain <script> tags it is about order.

With classic script tags there is no import statement, so a name is only available after the <script> that defines it has run. If your code references $ before the jQuery tag loads — or sits above it in the HTML — you get $ is not defined. Order the defining script first, or use defer / a module bundler so dependencies resolve before your code runs. If the name is a whole missing package rather than an unimported symbol, that is a different failure — see "Cannot find module."

Some names are not yours to declare — they are provided by the runtime. The catch is that Node.js and the browser provide different ones. Ask for a global the current environment never defined and you get a ReferenceError.

process, require, __dirname, and Buffer are Node globals; window, document, and localStorage are browser globals. Server-side rendering makes this especially common: a component runs on the Node server first, where window does not exist, then again in the browser, where it does. Guarding with typeof window !== 'undefined' — which, unlike a bare reference, never throws on an undeclared name — or moving the browser-only code into an effect that runs only on the client is the standard fix. For build-time values, use your bundler's mechanism (Vite's import.meta.env, a process polyfill, or a define plugin) rather than expecting Node's process to survive into the browser.

The name in the message tells you what is missing; the stack trace tells you where. The top frame is the exact file, line, and column that referenced the missing name — start there, confirm the spelling, then decide which of the five causes above applies. In production that frame often points into a minified bundle, so enable source maps in your build (or your error tracker) to resolve it back to your real source.

Most ReferenceErrors are catchable before the code ever executes. A linter with ESLint's no-undef rule flags a reference to any name that was never declared or imported — which covers typos, missing imports, and most scope mistakes in one pass. TypeScript goes further: it resolves every identifier against its declarations and its knowledge of which environment your file targets, so a browser global used in a Node file, or a name used before its declaration, becomes a compile error at your desk rather than a runtime crash for a user.

The one category tooling cannot fully save you from is the wrong-environment global in universal code, because whether window exists depends on where the module happens to run. There, a deliberate guard — or splitting the browser-only work into a client-only path — is the durable fix.