React Props vs State: What's the Difference?

Quick Answer

Props are read-only inputs a parent component passes down to a child; the child can use them but cannot change them. State is data a component owns and can change over time using a setter like the one from useState. Rule of thumb: if the value comes from outside, use props; if the component controls the value and it changes, use state.

Props vs State in React: The Short Version

If you are learning React, the question of props vs state react beginners keep asking usually comes down to one thing: who owns the data and who is allowed to change it. It sounds small, but getting it right is what makes your components predictable instead of buggy.

Here is the whole idea in two lines:

• Props are inputs passed into a component from its parent. The component reads them but must not change them. Think of them like arguments to a function.
• State is data a component owns. The component can change it over time, and when it does, React re-renders to show the new value.

That's the core distinction. The rest of this post shows you exactly what that looks like in real code, with a greeting example for props and a counter example for state, plus a simple guide for choosing between them.

What Are Props? (Read-Only Inputs)

"Props" is short for "properties." They are how a parent component sends data down to a child. You write them like HTML attributes, and the child receives them as an object.

Here is a small Greeting component that takes a name prop:

function Greeting(props) {
  return <h2>Hello, {props.name}!</h2>;
}

function App() {
  return (
    <div>
      <Greeting name="Aarav" />
      <Greeting name="Priya" />
    </div>
  );
}

Both Greeting calls use the same component but get different data. That is the power of props: one reusable component, many outputs.

Most React code destructures props to keep things tidy, which does exactly the same thing:

function Greeting({ name }) {
  return <h2>Hello, {name}!</h2>;
}

The single most important rule: props are read-only. Inside Greeting, you cannot write props.name = "Someone else". A child never changes the data it was handed. If it did, the parent and child would disagree about the truth, and your UI would become impossible to reason about.

What Is State? (Data a Component Owns and Changes)

Props come from outside, but sometimes a component needs its own data that changes over time: a text input's value, whether a menu is open, or a running count. That is what state is for.

In modern React (function components) you create state with the useState hook. Here is a classic counter:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

Let's unpack that line const [count, setCount] = useState(0):

• useState(0) sets the starting value to 0.
• count is the current value.
• setCount is the function you call to change it.

When you click the button, setCount updates the value and tells React to re-render the component. React runs Counter again, reads the new count, and shows the updated number. You never edit count directly, you always go through setCount. That's how React knows something changed.

Greeting vs Counter: Seeing the Difference

Put the two examples side by side and the distinction becomes obvious.

The Greeting component is controlled from outside. It does not decide what name to show; the parent decides by passing a prop. Greeting has no memory and nothing to change.

The Counter component is controlled from inside. Nobody hands it the count. It creates the count, owns it, and updates it in response to clicks.

You can even combine them. A parent can pass a starting number as a prop, and the child can hold its own count in state:

function Counter({ start }) {
  const [count, setCount] = useState(start);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

// Used like: <Counter start={10} />

Here start is a prop (an input from the parent), while count is state (owned and changed by the component). The prop seeds the state once; after that, the button controls the number on its own.

Key Differences at a Glance

Here is a quick comparison you can come back to.

One row needs a note. Props are read-only inside the component, so a child never changes its own props. But when the parent re-renders and passes a new prop value down, the child re-renders with that new value. So props do drive re-renders, just controlled from above rather than from inside, which is why that cell says "Partial."

Which Should You Reach For? A Quick Guide

When you are building a component and wondering whether a value should be a prop or state, ask these questions in order:

1. Does the value come from a parent component? If yes, it's a prop. Just receive it and use it.
2. Does the component change this value over time (clicks, typing, toggling)? If yes, it needs state.
3. Can you calculate it from existing props or state? If yes, don't store it at all, just compute it while rendering. Extra state you don't need is a common source of bugs.
4. Do two sibling components need to share the same changing value? Put the state in their closest common parent and pass it down as props. This pattern is called "lifting state up."

A simple mental model: state lives as high up as it needs to and flows down as props. The component that owns the data keeps it in state; everyone below just receives props.

Common Gotchas to Avoid

A few mistakes trip up almost every beginner. Watch for these.

1. Never mutate props

Props are read-only. Do not try to reassign them or push into a prop array. If a child needs a different value, the parent should compute it and pass it down, or the child should keep its own state.

2. Never change state directly

Always use the setter. This does not work as expected:

// Wrong: React doesn't know anything changed
count = count + 1;

Use the setter so React re-renders:

setCount(count + 1);

3. Use the updater form when new state depends on old state

If you update state based on its previous value, pass a function to the setter. This is the safe way, especially when several updates happen quickly:

setCount(prev => prev + 1);

4. Don't copy props into state unless you mean to

Setting state from a prop with useState(propValue) only reads that prop once, on the first render. Later prop changes won't update the state. That's fine when the prop is just an initial seed (like start earlier), but surprising if you expected it to stay in sync.

Our Recommendation

Start with props. Keep components as simple, predictable functions that take inputs and return UI. Only add state when a component genuinely needs to remember something that changes over time, like a count, a form field, or an open/closed toggle. Less state means fewer moving parts and fewer bugs.

When something needs to change, keep the state in the component that owns it, and pass what other components need down as props. This one-way flow, data down through props, changes handled by the owner through state, is the heart of how React works. Once it clicks, most React confusion disappears.

Want to go deeper with hands-on lessons and projects, all free? Work through the full React course on Priodemy, where you'll practice props, state, and hooks by building real components step by step.

Frequently Asked Questions