How to Fix the "Invalid Hook Call" Warning in React

The Invalid hook call warning is unusually blunt about where it happened and unusually silent about why. It hands you a stack trace and a one-line rule — hooks can only be called inside of the body of a function component — and leaves you to work out which of several very different problems you actually have. The good news is that React's own documentation narrows the field to exactly three causes, and once you know which one you're looking at, each has a direct fix.

To understand every one of these causes, you have to understand one implementation detail: React does not know the names of your hooks. When a component renders, React walks its hooks in order and keeps an internal list — first useState, then useEffect, then the next useState — matching each call to a slot by position. On the next render it expects the exact same calls in the exact same order so it can hand back the right state. That single design choice is the reason all three causes exist.

The most common cause is calling a hook somewhere its call order isn't stable. Because React matches hooks to state by position, a hook that runs on one render but not the next throws the whole list out of alignment. That's why the rules of hooks forbid calling a hook inside a condition, a loop, a nested function, an event handler, a class component, or anywhere after an early return.

The fix is always the same shape: move the hook to the top level so it runs on every render, and push the branching inside the hook (or after all hooks have been called). The same applies to loops — if you need a hook per item, you don't; lift the data into one hook and map over it, or split each item into its own child component that calls the hook once. The second half of the rule matters too: hooks may only be called from React function components or from other custom hooks (functions named useSomething), never from plain utility functions or class components.

Hooks were introduced in React 16.8, and the hook machinery is split across two packages: react exposes the hook functions, while react-dom (or React Native, or another renderer) supplies the runtime that actually stores hook state. If those two packages are on incompatible versions — say react@18 paired with an older react-dom — the renderer may not implement the hook contract the way react expects, and you get an invalid hook call. Check both:

Keep react and react-dom pinned to the same major and minor version. If you use a meta-framework like Next.js, let the framework dictate the React version rather than upgrading one package in isolation — a partial bump is the usual way this mismatch sneaks in.

This is the single most common — and most disorienting — cause, because your code can follow every rule and still throw. Hooks read state from a shared internal object (the dispatcher) that lives on the react module. There must be exactly one react in memory for that to work. When a bundler resolves two copies — commonly because a locally linked package (npm link) or a library brings its own react in its node_modules — a component rendered by copy A calls a hook that looks for the dispatcher on copy B, finds nothing, and React reports it as a hook called outside a component.

Start by confirming the duplicate. From your project root:

If you're the author of a library, don't ship React as a regular dependency at all — declare it as a peerDependency (and a devDependency for local builds) so consumers supply the single copy from their own app:

When the duplicate comes from npm link during local development, point the linked package's React back at the host app — either with a bundler alias (webpack resolve.alias / Vite resolve.dedupe: ['react', 'react-dom']) or by linking the host's react into the library. The goal is always the same: exactly one react and one react-dom resolved across the entire runtime.

The version-mismatch and duplicate-React causes share a nasty property: they're often invisible on your machine and only surface in a specific build. A duplicate can appear after a CI install resolves the dependency tree differently, after a teammate links a package, or only in the production bundle where a different React version got hoisted. You stare at code that's provably correct — because the bug isn't in the code, it's in the environment the code was assembled in.

This is also why the warning pairs so well with a systematic approach to React errors in general. If you want the broader workflow — reproducing an error, isolating the cause, and confirming the fix — see catch, reproduce, and fix React errors. For its close cousins, the render-loop crash lives in Maximum update depth exceeded, and the module-resolution failure that a broken link or dedupe can also trigger is covered in Cannot find module.

Every invalid hook call resolves to one of three answers, so work them in order:

• Rules of hooks — Is every hook called unconditionally, at the top level, from a component or a useSomething function? Move any hook out of conditions, loops, handlers, classes, and post-return code. Let eslint-plugin-react-hooks enforce it.
• Version match — Do react and react-dom report the same version under npm ls? Align them to the same major and minor.
• Single copy — Does npm ls react print exactly one React? If not, npm dedupe, add overrides, fix your library's peerDependencies, or alias the linked package back to the host's React.