When learning React, you may have noticed a component called <React.StrictMode> or <StrictMode> wrapped around your application.
At first, it can be confusing.
You might see a console.log() running twice, an Effect appearing to execute more than once, or behavior that seems different during development. Many developers initially think something is broken.
In most cases, React Strict Mode is intentionally helping you find potential problems before they reach production.
React Strict Mode is a development tool that helps identify unsafe code, unexpected side effects, and other potential issues in a React application.
In this article, we’ll understand what React Strict Mode does, why React may run certain code more than once, and when you should use it.
What Is React Strict Mode?
React Strict Mode is a built-in development feature that enables additional checks for components inside it.
You can think of it as an extra layer of development-time validation.
Your React App
│
▼
React Strict Mode
│
▼
Extra Development Checks
│
▼
Potential Problems Found Earlier
Strict Mode does not change how your application’s UI looks.
It also does not add a visible element to your page.
Instead, it helps React detect certain patterns that could cause problems as your application becomes more complex.
A basic setup may look like this:
<StrictMode>
<App />
</StrictMode>
The important thing to remember is:
Strict Mode is mainly designed to help developers during development.
Why Does React Need Strict Mode?
JavaScript applications can contain bugs that are difficult to notice immediately.
For example:
- A component accidentally changes external data while rendering.
- An Effect does not clean up correctly.
- A component relies on behavior that may cause problems later.
- Code produces unexpected side effects.
These problems may not always be visible when the application first runs.
React Strict Mode intentionally performs additional checks so these issues become easier to discover.
Instead of waiting until users report a bug, developers can identify suspicious behavior earlier.
What Does React Strict Mode Actually Do?
Strict Mode enables additional development checks for the part of the component tree wrapped inside it.
Depending on your React version and application setup, these checks can help identify issues involving:
- Impure rendering
- Missing Effect cleanup
- Incorrect assumptions about component lifecycle behavior
- Deprecated or unsafe APIs
- Code that behaves incorrectly when React reuses or re-runs components
One of the most noticeable behaviors is that React may intentionally call certain functions more than once during development.
This is where much of the confusion begins.
Why Does console.log Run Twice?
Suppose you write:
function App() {
console.log("Component rendered");
return <h1>Hello React</h1>;
}
With Strict Mode enabled in development, you may see:
Component rendered
Component rendered
This does not necessarily mean your application has rendered twice in production.
React may intentionally re-run rendering-related logic during development to help detect code that produces unexpected side effects.
For example, rendering should not directly do things such as:
- Modify global variables
- Make API requests
- Update external data
- Change objects unexpectedly
A React component’s render logic should ideally be predictable.
Given the same inputs, it should produce the same UI result without causing unexpected side effects.
Strict Mode helps expose situations where this rule is being broken.
Strict Mode and Pure Components
A useful way to understand Strict Mode is through the idea of purity.
A component should generally behave predictably.
For example:
Same Props + Same State
│
▼
Same UI Output
A problematic component might also change something outside React while rendering:
Render Component
│
├── Return UI
│
└── Unexpectedly modify external data
This can make applications harder to debug.
Strict Mode may expose these kinds of problems by intentionally re-running certain logic in development.
If running the code again creates unexpected results, it may indicate that the component is doing something it should not do during rendering.
Strict Mode and useEffect
Another common source of confusion is useEffect.
Developers sometimes write an Effect like this:
useEffect(() => {
console.log("Effect started");
}, []);
Then, in development with Strict Mode, they may see the Effect behavior more than once.
This can feel strange because the dependency array is empty.
The key point is that Strict Mode can intentionally perform an additional setup and cleanup cycle in development to help reveal missing cleanup logic.
Conceptually, React may test your Effect like this:
Setup Effect
↓
Cleanup Effect
↓
Setup Effect Again
This helps answer an important question:
If your component is removed and set up again, does your Effect clean up correctly?
Why Effect Cleanup Matters
Imagine your component creates something outside React.
For example:
- A WebSocket connection
- An event listener
- A timer
- A subscription
When the component is no longer using that resource, it should usually clean it up.
Conceptually:
Component Mounts
│
▼
Create Connection
│
▼
Component Unmounts
│
▼
Close Connection
If cleanup is missing, your application may accidentally create multiple connections, listeners, or timers.
Strict Mode makes these problems easier to notice during development.
For example, the proper pattern for an Effect is conceptually:
useEffect(() => {
// Setup
return () => {
// Cleanup
};
}, []);
Not every Effect requires cleanup, but when you create subscriptions, listeners, connections, or similar external resources, cleanup becomes important.
Strict Mode Does Not Affect Production the Same Way
One of the most important things to understand is that Strict Mode’s additional development checks are intended for development.
A production build does not behave like the development environment with these extra Strict Mode checks.
So if you see something like:
Console log → Twice
Effect setup → Additional development check
that does not automatically mean users will experience duplicated behavior in production.
However, you should not simply ignore duplicated behavior.
Strict Mode may be revealing a genuine issue in your code.
For example, if an API request is accidentally triggered twice because your Effect is poorly structured, the goal should be to understand why the Effect behaves that way rather than immediately disabling Strict Mode.
Strict Mode Helps Find Side Effects
Let’s understand the difference between good and problematic rendering behavior.
Predictable rendering
Render Component
│
▼
Read Props and State
│
▼
Return JSX
Rendering with unwanted side effects
Render Component
│
├── Return JSX
│
├── Change external variable
├── Make unexpected API request
└── Modify existing data
React rendering should focus primarily on calculating what the UI should look like.
Side effects usually belong in the appropriate place, such as an event handler or an Effect, depending on what the code is doing.
Strict Mode helps developers identify code that mixes these responsibilities incorrectly.
Common Strict Mode Problems Developers Notice
1. Duplicate Console Logs
This is often the first thing developers notice.
A component may appear to run more than once in development.
The first question should be:
Is my component changing anything outside itself while rendering?
If the answer is yes, that logic may need to be moved elsewhere.
2. API Requests Appearing Multiple Times
Sometimes developers notice duplicate API requests during development.
This can happen when Effect logic is not designed correctly or when development behavior exposes missing cleanup or request-handling logic.
Instead of removing Strict Mode immediately, check:
- Is the request in the correct Effect?
- Does the Effect have the correct dependencies?
- Is cleanup needed?
- Is the component being mounted or rendered differently than expected?
- Would a dedicated data-fetching solution better handle the request lifecycle?
Understanding the cause is better than simply hiding the behavior.
3. Multiple Event Listeners
Imagine an Effect that adds an event listener but never removes it.
Conceptually:
Effect Runs
↓
Add Event Listener
↓
Effect Runs Again
↓
Add Another Listener
Now the same event might trigger multiple handlers.
A cleanup function helps prevent this:
Effect Setup
│
▼
Add Listener
│
▼
Cleanup
│
▼
Remove Listener
Strict Mode can help expose this type of problem.
4. Timers That Continue Running
The same issue can happen with timers.
For example:
Component Starts
↓
Create Timer
↓
Component Changes or Unmounts
↓
Timer Still Running ❌
The timer should generally be cleaned up when it is no longer needed.
Strict Mode can make missing cleanup easier to notice during development.
Strict Mode Is Not an Error
Seeing repeated logs or development checks does not mean Strict Mode itself is causing a bug.
Strict Mode is a debugging and development aid.
Think of it like a code reviewer that asks:
- What happens if this logic runs again?
- Does this Effect clean up correctly?
- Is this component pure?
- Is this code relying on unsafe behavior?
The goal is to make your application more reliable.
Should You Disable React Strict Mode?
In general, you should avoid disabling Strict Mode simply because you see duplicate logs or unexpected development behavior.
Instead, first investigate the reason.
Ask yourself:
- Is my component performing side effects during rendering?
- Does my Effect need cleanup?
- Are my dependencies correct?
- Am I accidentally creating subscriptions or listeners multiple times?
- Is my data-fetching logic structured properly?
Strict Mode can sometimes reveal code that appears to work today but may become difficult to maintain later.
That said, developers may temporarily remove Strict Mode while debugging a specific third-party compatibility issue. But it is generally better to understand and fix the underlying cause where possible.
Can You Use Strict Mode for Only Part of an Application?
Yes.
Strict Mode can be applied to a specific section of your component tree.
Conceptually:
App
│
├── Header
│
├── Strict Mode
│ │
│ ├── Dashboard
│ └── Profile
│
└── Footer
The additional checks apply to the components inside the Strict Mode boundary.
This can be useful when gradually working with a large application.
Strict Mode vs Production Mode
Here is a simple comparison:
| Development with Strict Mode | Production |
|---|---|
| Additional development checks | Optimized for users |
| Helps detect potential issues | No development-only Strict Mode checks |
| Some functions may be intentionally re-run | Normal production behavior |
| Useful for debugging | Focused on delivering the application |
The exact behavior can depend on your React version and setup, but the main idea remains the same:
Strict Mode is designed to help developers catch problems early without adding production behavior just for those checks.
Best Practices When Using Strict Mode
Keep rendering pure
Avoid modifying external values directly while rendering a component.
Rendering should primarily calculate and return the UI.
Clean up Effects properly
If an Effect creates:
- Event listeners
- Timers
- WebSocket connections
- Subscriptions
make sure those resources are cleaned up when necessary.
Avoid using effects for everything
Not every piece of logic needs useEffect.
If something can be calculated directly from props or state during rendering, an Effect may be unnecessary.
Using fewer unnecessary Effects can make your application easier to understand.
Understand development behavior
Do not assume that repeated logs automatically mean a production problem.
Check whether Strict Mode is intentionally exposing a weakness in the component.
Don’t disable Strict Mode as the first solution
Treat Strict Mode as useful feedback.
Fixing the underlying issue usually produces better and more reliable React code.
A Simple Mental Model
If React Strict Mode feels complicated, remember this:
Write Component
│
▼
Strict Mode Tests Development Behavior
│
▼
Potential Problem Detected?
│
┌───┴────┐
│ │
Yes No
│ │
▼ ▼
Fix Code Continue
Strict Mode is essentially helping you test whether your React code behaves correctly under additional development checks.
Final Thoughts
React Strict Mode is one of those features that can initially feel annoying—especially when you see console.log() messages appearing twice or an Effect behaving differently during development.
But its purpose is valuable.
Strict Mode helps expose problems involving:
- Unexpected side effects
- Impure rendering
- Missing Effect cleanup
- Incorrect assumptions about component behavior
- Code patterns that may become problematic as an application grows
The most important thing is not to treat Strict Mode as something that causes bugs.
Instead, think of it as a tool that helps reveal bugs and risky patterns earlier.
A simple way to remember it is:
Strict Mode makes React development stricter so your application can become more reliable.
For React developers, understanding Strict Mode is especially important because it encourages better habits: keeping render logic pure, writing Effects carefully, and cleaning up external resources correctly.
FAQs
Does React Strict Mode run in production?
Strict Mode’s additional development checks are intended for development. Production builds do not include those development-only checks in the same way.
Why does console.log run twice in React?
In development, Strict Mode may intentionally re-run certain rendering-related logic to help detect unexpected side effects and impure code.
Does Strict Mode make my application slower?
Its additional checks are primarily for development and are not intended to add the same debugging overhead to production builds.
Should I remove Strict Mode if my API is called twice?
Not immediately. First investigate why the request is occurring more than once and check your Effect logic, cleanup, dependencies, and component lifecycle behavior.
Is Strict Mode required in React?
No. React applications can run without it, but it is a useful development tool for identifying potential problems early.
Can Strict Mode be used for only some components?
Yes. You can place a Strict Mode boundary around a specific part of your component tree, and its checks apply within that section.
