How to fix Type of prop does not match expected type in React
This error occurs when a React component receives a prop whose type does not match the expected type definition, either through PropTypes validation or TypeScript type checking. It indicates a mismatch between what the component expects and what is actually being passed.
Quick fix
Fixes Type of prop does not match expected type
Failed prop type: Invalid prop `count` of type `string`
supplied to `Counter`, expected `number`- Identify the specific prop causing the error
- Check the component's prop definition
- Fix the prop being passed to match the expected type
- Update the prop definition if the type expectation is wrong
Failed prop type: Invalid prop `count` of type `string`supplied to `Counter`, expected `number`Type of prop does not match expected type
What this error means
This error appears in two main contexts in React development: when using PropTypes for runtime validation or when using TypeScript for compile-time type checking. In PropTypes-based projects, this manifests as a console warning in development mode when a prop's actual type doesn't match its PropTypes definition. For example, passing a string "123" when PropTypes.number is expected will trigger this warning. In TypeScript projects, this is a compile-time error that prevents your code from building. TypeScript checks that every prop passed to a component matches its type definition exactly. This can occur with basic type mismatches (string vs number), missing required props, or incompatible complex types (objects, arrays, unions). The error serves as a safety mechanism to catch bugs early—before they reach production—by ensuring components receive the correct data types they're designed to handle. While PropTypes only warns at runtime in development, TypeScript prevents compilation entirely, making it a more robust solution for type safety.
Typical symptoms
- Console warning: "Failed prop type: Invalid prop `propName` of type `X` supplied to `ComponentName`, expected `Y`"
- TypeScript compiler error preventing build from completing
- Component receives data but behaves unexpectedly due to type coercion
- ESLint warnings about missing prop validation
- Props marked as required but not provided, causing undefined errors
- Runtime errors when component tries to use prop methods that don't exist on the wrong type
Common causes
- Passing a string where a number is expected (e.g., "42" instead of 42)
- Passing a number where a string is expected
- Omitting required props when rendering a component
- Passing null or undefined to a prop that expects a specific type
- Providing an object with wrong shape or missing properties
- Passing a function with incorrect signature
- Using incompatible union types (passing a type not in the union)
- Passing an array when a single value is expected, or vice versa
- Type inference failures in complex generic components
- Missing PropTypes definitions for used props
How to fix "Type of prop does not match expected type"
Check the error message to identify which prop and component are involved:
Failed prop type: Invalid prop `count` of type `string`
supplied to `Counter`, expected `number`For TypeScript errors, the compiler will show:
Type 'string' is not assignable to type 'number'Look at both the component definition and where it's being used to understand the mismatch.
For PropTypes, verify the prop definition in the component:
import PropTypes from 'prop-types';
function Counter({ count }) {
return <div>Count: {count}</div>;
}
Counter.propTypes = {
count: PropTypes.number.isRequired, // Expects number
};For TypeScript, check the interface or type definition:
interface CounterProps {
count: number; // Expects number
}
function Counter({ count }: CounterProps) {
return <div>Count: {count}</div>;
}Convert the value to the correct type when passing it:
Wrong:
<Counter count="42" /> {/* String instead of number */}Correct:
<Counter count={42} /> {/* Number */}For dynamic values, convert them explicitly:
const countStr = "42";
<Counter count={Number(countStr)} />
// or
<Counter count={parseInt(countStr, 10)} />For optional props, handle undefined cases:
<Counter count={maybeCount ?? 0} />If the component should actually accept multiple types, update the definition:
PropTypes with multiple types:
Counter.propTypes = {
count: PropTypes.oneOfType([
PropTypes.string,
PropTypes.number,
]).isRequired,
};TypeScript union types:
interface CounterProps {
count: string | number;
}Make props optional:
interface CounterProps {
count?: number; // Optional with ?
}
// Or with PropTypes:
Counter.propTypes = {
count: PropTypes.number, // Not required
};For objects and arrays, ensure the structure matches:
Wrong:
interface User {
id: number;
name: string;
email: string;
}
// Missing email property
<UserCard user={{ id: 1, name: "John" }} />Correct:
<UserCard user={{ id: 1, name: "John", email: "john@example.com" }} />For complex validation, use custom PropTypes:
Counter.propTypes = {
user: PropTypes.shape({
id: PropTypes.number.isRequired,
name: PropTypes.string.isRequired,
email: PropTypes.string.isRequired,
}).isRequired,
};Advanced notes
PropTypes vs TypeScript: PropTypes provide runtime validation only in development mode and are stripped in production builds. TypeScript provides compile-time type safety but doesn't check types at runtime. Many modern React projects use TypeScript exclusively and remove PropTypes entirely. However, some projects use both for defense-in-depth, where TypeScript catches errors during development and PropTypes catch errors from external data sources or dynamically loaded code.
Type Coercion Pitfalls: JavaScript's loose typing can mask type issues. For example, passing "42" to a component expecting a number might not immediately fail because many operations work on both strings and numbers. However, operations like arithmetic will produce unexpected results ("42" + 1 = "421" instead of 43). Always be explicit with types in React props.
Generic Components: When building generic components with TypeScript, use proper type constraints to ensure props match expected patterns. Inference can fail in complex scenarios, requiring explicit type parameters: <DataList<User> items={users} />.
defaultProps Deprecation: In React 18+, defaultProps is deprecated for function components. Use default parameter values instead: function Counter({ count = 0 }: CounterProps). This provides better TypeScript inference and aligns with modern JavaScript patterns.
ESLint Integration: The react/prop-types ESLint rule can detect missing PropTypes definitions. In TypeScript projects, you can safely disable this rule in your ESLint config since TypeScript provides superior type checking. Add "react/prop-types": "off" to your rules configuration.
Debugging Tips: When facing type mismatches in large component trees, use React DevTools to inspect the actual prop values being passed at runtime. Compare these with your type definitions to identify where the mismatch originates. For TypeScript errors, use // @ts-expect-error comments temporarily to isolate the problematic prop while fixing it.
Frequently asked questions
- What does "Type of prop does not match expected type" mean?
- This error appears in two main contexts in React development: when using PropTypes for runtime validation or when using TypeScript for compile-time type checking. In PropTypes-based projects, this manifests as a console warning in development mode when a prop's actual type doesn't match its PropTypes definition. number is expected will trigger this warning.
- How do I fix "Type of prop does not match expected type"?
- This error occurs when a React component receives a prop whose type does not match the expected type definition, either through PropTypes validation or TypeScript type checking. It indicates a mismatch between what the component expects and what is actually being passed.
- What causes "Type of prop does not match expected type"?
- Passing a string where a number is expected (e.g., "42" instead of 42) Passing a number where a string is expected Omitting required props when rendering a component
- Is the "Type of prop does not match expected type" error serious?
- It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.