If you have spent any meaningful time writing JavaScript, you have almost certainly seen it — the dreaded TypeError: undefined is not a function. It shows up in the browser console, it stops your code dead in its tracks, and it tends to appear at the worst possible moment. The good news is that, once you understand what is really going on, it is entirely fixable and, better yet, entirely preventable.

In this article we are going to walk through what this error actually means, why JavaScript throws it, and the most common situations where it tends to surface. Along the way we will look at practical fixes and a few habits that will stop the error from coming back. Let’s dive in.

What Does the Error Actually Mean?

At its simplest, TypeError: undefined is not a function means exactly what it says: JavaScript tried to call something as if it were a function, but when it looked at the value, it found undefined instead. JavaScript is a loosely typed language, which means types are not checked at compile time. The engine only discovers the problem when it actually tries to execute the call. At that point, it throws a TypeError.

There are a handful of situations that trigger this. They are all different on the surface, but they all share the same root: something that should be a function is not. Understanding each one helps you pinpoint the real source of the bug, rather than guessing.

Most common root causes of “undefined is not a function”

Cause 1: The Typo You Did Not Notice

This is the single most common trigger, and it also happens to be the easiest to fix once you spot it. JavaScript is case-sensitive, so fetchData() and FetchData() are two completely different things. Similarly, even a transposed letter like calcluateSum() instead of calculateSum() is enough to cause the error.

For example, the following code will fail because the function name is misspelled at the call site:

function calculateSum(a, b) {
 return a + b;
}

// ❌ Typo — 'calcluate' instead of 'calculate'
calcluateSum(5, 10); // TypeError: calcluateSum is not a function


// ✅ Correct spelling
calculateSum(5, 10); // 15

The fix is straightforward: double-check spelling at both the declaration and every call site. A good IDE like VS Code will underline unrecognised identifiers, which makes this class of bug much easier to catch before you even run the code.

Cause 2: Hoisting and the Function Expression Trap

JavaScript hoists declarations to the top of their scope before execution begins. However, hoisting behaves differently depending on how you define your function, and this is where a lot of developers get caught out.

A classic function declaration is fully hoisted — meaning you can call it before it appears in the file. A function expression (where you assign an anonymous function to a variable) is a different story. If you use var, the variable itself is hoisted but its value stays undefined until the assignment line is reached. The result is predictable: calling it early throws our familiar error.

// ✅ Function declaration — hoisting works, call before definition is fine
greet(); // "Hello!"

function greet() {
 console.log("Hello!");
}

// ❌ Function expression with var — var is hoisted as undefined
sayHi(); // TypeError: sayHi is not a function

var sayHi = function() {
 console.log("Hi!");
};

// ✅ Move the call after the assignment
var sayHi = function() {
 console.log("Hi!");
};
sayHi(); // "Hi!"

Quick rule of thumb: If you use const or let for function expressions (which is the modern, recommended approach), JavaScript will throw a ReferenceError rather than a TypeError if you call too early — because let and const are not initialised during hoisting. Either way, the lesson is the same: define before you call.

Hoisting behaviour at a glance

Cause 3: Calling a Method on the Wrong Type

This one catches developers frequently, especially when data comes from an API or another source that does not always return what you expect. For instance, .map(), .filter(), and .forEach() are Array methods. If the variable turns out to be null, undefined, or even a plain object, calling those methods will immediately throw.

// Imagine this came back from an API that returned null on error
const users = null;

// null has no .map() method
users.map(u => u.name); // TypeError: Cannot read properties of null


// Guard with a default value or an explicit check
const safeUsers = users ?? [];
safeUsers.map(u => u.name); // [] — safe and predictable

Similarly, accidentally calling a string method on a number, or an array method on an object, produces the same family of errors. The best defence is to validate your data before operating on it, and to use defensive defaults (?? [], ?? {}) at the point where external data enters your code.

Watch for typos in method names too. .forEach and .forEachh look almost identical at a glance. JavaScript will look up the property and find undefined, then try to call it — resulting in exactly our TypeError.

Cause 4: Async Timing Issues

Asynchronous code is another frequent source of this error, particularly for developers who are still getting comfortable with how JavaScript handles timing. The problem typically goes like this: a function is fetched or loaded asynchronously, and somewhere else in the code it gets called before the async operation has finished. At the point of the call, the variable still holds undefined.

// Calling the result of a Promise before it resolves
let processData;

fetch("/api/processor")
 .then(res => res.json())
 .then(data => {
 processData = data.handler;
 });

// This runs immediately — processData is still undefined here
processData(); // TypeError: undefined is not a function


// Keep the call inside the .then() block, or use async/await
async function run() {
 const res = await fetch("/api/processor");
 const data = await res.json();
 const processData = data.handler;
 
processData(); // Runs only after data is ready

}

run();

The async/await pattern is generally the clearest way to handle this. It makes the order of operations obvious and, as a result, makes these timing bugs far less likely to slip through.

Cause 5: Scope Problems

JavaScript’s scoping rules mean that a function defined inside one block is not necessarily available in another. In addition, if you accidentally reassign a variable that was holding a function reference, you lose the function entirely and replace it with whatever the new value is.

// ❌ Function defined inside a block — not accessible outside
if (true) {
 function helper() {
 return "I help!";
 }
}
// In strict mode or modules, helper() here may be undefined

// ❌ Overwriting a function reference
let doWork = function() { console.log("working"); };
doWork = "oops"; // now it's a string
doWork(); // TypeError: doWork is not a function


// ✅ Use const to prevent accidental reassignment
const doWork = function() { console.log("working"); };

// Reassigning const throws a TypeError at assignment time — caught early

Preferring const for function expressions is a small but effective habit. It closes off one entire category of bugs by making accidental reassignment a runtime error at the point of reassignment, rather than a mysterious failure somewhere else later.

Cause 6: Import and Export Mismatches

As codebases grow and modules come into play, import/export mistakes become a regular source of this error. The two most common culprits are mixing up default and named exports, and getting the file path wrong.

// utils.js — named export
export function calculateTax(amount) { return amount * 0.2; }


// main.js — ❌ Wrong: importing as default
import calculateTax from "./utils.js"; // undefined!

calculateTax(100); // TypeError: calculateTax is not a function

// main.js — ✅ Correct: use curly braces for a named export
import { calculateTax } from "./utils.js";

calculateTax(100); // 20

As a rule: default exports are imported without curly braces, named exports require them. When something is undefined despite being imported, this distinction is usually the first thing worth checking. The MDN guide on ES Modules has a clear breakdown if you need a refresher.

Time spent debugging vs. prevention — a developer experience comparison

How to Debug It When You Are Not Sure Which Cause You Are Dealing With

Sometimes the stack trace makes the problem obvious. Other times — particularly in larger applications — you end up staring at a line number that points to a call site, not the root cause. In those situations a methodical approach saves a lot of time.

Start by printing the value before you call it. Add console.log(typeof myValue, myValue) immediately before the line that fails. If typeof returns "undefined", the variable was never assigned. If it returns "string" or "object", you have a type mismatch. That single check usually narrows things down to one of the causes above.

Beyond typeof, modern browser DevTools let you set a breakpoint directly on the line that throws. From there you can hover over any variable and inspect its current value without adding a single console statement. The Chrome DevTools documentation is a great reference if you are not yet fully comfortable with breakpoints.

Prevention: A Few Habits That Make a Real Difference

Fixing a bug once is satisfying. Not seeing it again is even better. Fortunately, a small set of consistent habits covers the vast majority of cases that cause this particular error.

First, lean toward const for every function expression. It makes accidental overwriting impossible and signals clearly that this value should not change. Second, validate external data at entry points — whether that is an API response, a user input, or a module export. Third, prefer async/await over deeply nested .then() chains; the linear structure makes execution order much easier to reason about. Finally, use a linter. ESLint with the no-use-before-define rule catches hoisting mistakes automatically, before they ever reach the browser.

If your project allows it, TypeScript takes prevention a step further. By assigning types to your variables and function signatures, the compiler flags mismatches at build time — so a string being called as a function becomes a compile error rather than a runtime surprise.

What We Learned

The TypeError: undefined is not a function error is one of JavaScript’s most common runtime failures, but it is always traceable to a concrete root cause. We covered the six main triggers: typos and case-sensitivity mistakes, the hoisting gap between function declarations and function expressions, calling methods on the wrong data type, async timing where a function is called before an async operation resolves, scope and accidental overwrite issues, and import/export mismatches in modular code. We also walked through a systematic debugging approach — using typeof and browser DevTools breakpoints — to narrow down the cause quickly. Finally, we saw how a handful of consistent habits, from preferring const and async/await to adding ESLint and, where possible, TypeScript, can prevent most occurrences of this error before they ever reach production.