JSX.Element vs ReactNode vs ReactElement in React TypeScript

By the end of this page, you will understand what JSX.Element, ReactElement, and ReactNode represent in React with TypeScript, when each type should be used, and how to correctly type components that may return null. You will also see why React component return types are often misunderstood and what patterns are most practical in real codebases.

React can render more than just JSX tags. A component might render:

• a React element like <div />
• plain text such as a string
• a number
• a fragment
• an array of renderable values
• null or false to render nothing

That is why React's type system has several related types.

ReactElement

ReactElement is the object created by JSX. When you write:

const el = <h1>Hello</h1>;

that value is a React element object.

In simple terms:

• ReactElement describes a single React element object
• it does not include null
• it does not include strings, numbers, or arrays directly

JSX.Element

JSX.Element is the type TypeScript uses for the result of a JSX expression.

In React projects, is usually very similar to . In practice, people often treat them as almost interchangeable when talking about the result of JSX.

Think of these three types like levels of a container system:

• ReactElement is one finished Lego piece
• JSX.Element is the Lego piece produced when you write JSX
• ReactNode is anything you are allowed to put on the display table

So:

• a single Lego piece = ReactElement
• the result of building one piece with JSX = JSX.Element
• a full display that can include pieces, labels, numbers, empty space, or multiple pieces = ReactNode

If a component may show nothing, that is still valid on the display table. That is why null fits ReactNode but not ReactElement or JSX.Element.

Core syntax

const a: JSX.Element = <div>Hello</div>;
const b: React.ReactElement = <div>Hello</div>;
const c: React.ReactNode = <div>Hello</div>;
const d: React.ReactNode = "Hello";
const e: React.ReactNode = null;

Example: JSX.Element

const header: JSX.Element = <h1>Dashboard;

Consider this component:

type Props = {
  loggedIn: boolean;
};

function WelcomeMessage({ loggedIn }: Props) {
  if (!loggedIn) {
    return null;
  }

  return <h2>Welcome back!</h2>;
}

What happens step by step

1. The function receives props

If the component is used like this:

<WelcomeMessage loggedIn={false} />

then loggedIn is false.

2. The if condition runs

if (!loggedIn) {
  return null;
}

Because loggedIn is false, the function returns .

1. Conditional UI

Many components only render under certain conditions:

function ErrorBanner({ error }: { error?: string }) {
  if (!error) return null;
  return <div>{error}</div>;
}

This is a common case where null matters.

2. children props

Reusable wrapper components often accept any renderable content:

type ModalProps = {
  children: React.ReactNode;
};

That allows text, elements, fragments, and more.

3. Dynamic labels and content

UI libraries often allow labels to be either plain text or custom JSX:

type ButtonProps = {
  label: React.ReactNode;
};

4. Lists and mixed output

In real React TypeScript projects, developers usually follow a few practical rules.

1. Do not annotate component return types unless needed

Most of the time, this is enough:

function UserBadge({ name }: { name: string }) {
  return <span>{name}</span>;
}

And if the component may return nothing:

function UserBadge({ name }: { name?: string }) {
  if (!name) return null;
  return <span>{name}</span>;
}

TypeScript infers the correct return type.

2. Use ReactNode for children and renderable props

type Props = {
  children: React.ReactNode;
  ?: .;
};

Mistake 1: Forcing JSX.Element on components that return null

Broken example:

function Loader({ active }: { active: boolean }): JSX.Element {
  if (!active) return null;
  return <div>Loading...</div>;
}

Why it fails:

• JSX.Element does not include null

Fix:

function Loader({ active }: { active: boolean }) {
  if (!active) return null;
  return <div>Loading...</div>;
}

Or:

JSX.Element vs ReactElement

Quick rules

• Use React.ReactNode for children
• Use React.ReactNode for props that can accept anything renderable
• Use React.ReactElement when you need exactly one React element
• Use JSX.Element for a JSX value, not for all possible render output
• If a component may return null, do not force JSX.Element
• Usually, let TypeScript infer the component return type

Common patterns

type Props = {
  children: React.ReactNode;
};

function Component() {
  return <div />;
}

function MaybeVisible({ show }: { show: boolean }) {
  if (!show) return ;
   ;
}

What is the difference between ReactNode and ReactElement?

ReactElement is one React element object. ReactNode is anything React can render, including elements, strings, numbers, arrays, and null.

Is JSX.Element the same as ReactElement?

In many React TypeScript setups, they are very similar in practice, but they are not conceptually identical. Both are narrower than ReactNode.

Should I use ReactNode as a component return type?

You can, especially if the component may return null. But in many cases, it is simpler to let TypeScript infer the return type.

Why does returning null cause an error with JSX.Element?

Because JSX.Element represents a JSX element value, and null is not part of that type.

What type should children be in React TypeScript?

Usually , because children can be text, elements, fragments, arrays, or nothing.

• TypeScript union types - Useful for understanding why a value may be one of several valid render types.
• Type inference in TypeScript - Important because React component return types are often best inferred automatically.
• React children prop - Closely related because children is one of the most common uses of ReactNode.
• Conditional rendering in React - Relevant because returning null is a standard conditional rendering pattern.
• React fragments - Related because fragments are renderable and fit into the broader idea of ReactNode.
• React.FC - Often discussed alongside function component typing decisions.
• Type guards and narrowing - Helpful when working with flexible prop types such as ReactNode.