How to Fix "Objects Are Not Valid as a React Child"

Objects are not valid as a React child (found: object with keys {…}) looks intimidating, but it comes from a single, simple rule that is worth memorising before you touch anything: React only knows how to render a fixed set of things. Strings and numbers become text. React elements (the output of JSX or createElement) become DOM. Booleans, null, and undefined render nothing. And arrays render as long as every item is one of those. That is the whole list — it is exactly what React's TypeScript types call a ReactNode: the broad union of everything renderable. Hand a JSX child slot anything outside that union — most commonly a plain object — and React refuses to guess how to display it and throws instead.

Notice the two helpful halves of the message. First, found: object with keys {name, email} tells you the shape of the thing you handed it — those keys are your clue to which variable is the object and which property you actually meant to show. Second, the full message usually ends with "If you meant to render a collection of children, use an array instead" — React nudging you toward .map() when the object you passed was really meant to be a list. Every version of this bug has the same shape: a {something} in your JSX where something evaluated to an object instead of a printable value.

It helps to know why the line is drawn there. A number like 42 is a valid React node but not a valid React element; an object is neither. React's renderable union — ReactNode — deliberately excludes plain objects because there is no one correct way to stringify them. { id: 3, name: 'Ada' } could reasonably display as its id, its name, or its JSON, and any choice React made would surprise half its users, so it makes none and throws. That single design decision, documented in React's own JSX-with-curly-braces guide, is the root of every case below.

Almost every occurrence is one of these six. Each fix is the same idea — tell React precisely what to display — applied to a different kind of value.

This is the number-one cause and usually a plain typo: you wrote {user} when you meant {user.name}. The message's keys {id, name, email} hint points you straight at the property you forgot to reach into.

The classic beginner slip. In JSX the outer braces open a JavaScript expression, so the inner braces build an object literal — {{ message }} evaluates to { message: message }, a whole object. As bobbyhadz's write-up puts it, React thinks you are trying to render an object, so it throws; the fix is a single set of braces. The one time double braces are correct is an inline style object — style={{ color: 'red' }} — because style genuinely expects an object, not a rendered child.

Date catches people out because it feels primitive, but typeof new Date() is "object". Pick the string form you want: toLocaleDateString() for a human-readable local date, toLocaleString() for date and time, or toISOString() when you need a stable machine-readable stamp. Render the returned string, never the Date itself. If you format many dates in a list, MDN recommends building one Intl.DateTimeFormat instance and reusing its format(): every toLocaleDateString call searches a large localization database, so a reused formatter that caches its locale settings is measurably faster than calling the toLocale* methods per row.

An async function or any .then() chain returns a Promise — an object — immediately, long before the data arrives. Rendering it hands JSX the promise, not the result. Resolve it outside render (in a useEffect or an event handler), store the resolved value in state, and render that value. At a different layer, the same fix has framework-native forms: an async Server Component in Next.js can await the data before it returns JSX, and you can even pass an unresolved promise down as a prop to be unwrapped by React 19's use hook inside a <Suspense> boundary. In every case the principle holds: never put the promise itself in a child slot. See uncaught (in promise) errors for the related failure mode where the promise rejects instead.

An array is renderable only when every item is — an array of strings works, an array of objects does not. Map each object to a React element and render a specific field inside it. React's rendering-lists guide is explicit that JSX elements produced directly inside a map() always need a key, and that the key should be a stable id that uniquely identifies the item among its siblings — not the array index, which breaks re-render tracking as soon as items are sorted, inserted, or removed.

This one is sneaky because console.log(error) prints readable text, so it feels renderable — but an Error is still an object, and its message is not an own-enumerable key, so you often see the bare found: object with keys {}. Render error.message for the human text, or coerce with String(error). Because a caught value can technically be anything (someone may throw 'oops' or throw { code: 500 }), the error instanceof Error ? error.message : String(error) guard is the pattern that never throws a second error inside your error UI.

When you genuinely just want to see what an object contains, JSON.stringify(value, null, 2) turns it into an indented, printable string, which JSX will happily render:

Often you do not even need to render the object to inspect it — the console is better at it. Chrome DevTools' Console Utilities give you console.table(users), which lays an array of objects out as a sortable grid with a column per key, and console.dir(obj), which prints an expandable property tree instead of DOM markup. Reaching for those first keeps debugging output out of your component tree entirely, so you never accidentally ship a <pre> dump — and you sidestep this error while you investigate.

Here is the pattern worth internalising: this error rarely means your JSX is wrong in isolation. It usually means the data arrived in a different shape than your component assumed. You wrote {user.name} expecting name to be a string, but the API nested it under user.name.first, or returned user as { value: {...} }, or wrapped the whole payload in { data: [...] }. Your code accesses one level too shallow and hands an object to JSX. That is the same class of bug behind cannot read properties of undefined — one assumes a field exists, the other assumes it is a primitive — and both are really "the response wasn't the shape I coded for." It also overlaps with hydration errors when the server and client disagree on that shape.

Because the trigger lives in the data, reproducing it means seeing the actual response and props at the moment it threw — not the fixture your local dev server serves, which conveniently always has the right shape. The systematic way to close that gap is covered in React error tracking: catch, reproduce, fix.

Reaching for the nearest property that makes the error disappear can hide a real problem. A few honest caveats:

• Don't paper over the shape bug. If {user} threw because the API returned { data: { user } }, changing it to {user.data.user.name} works but leaves your types lying. Fix the access point (or the response contract) so the rest of the component reads correctly too.
• Empty and partial data still bites. {items.map(...)} is right, but if items can be undefined during loading you'll trade this error for "cannot read properties of undefined." Guard with a default ((items ?? []).map) or a loading state.
• Locale formatting is a product decision. toLocaleDateString() renders differently per user locale and timezone, which can cause a server/client mismatch during hydration. If you need a fixed format, pass an explicit locale and timeZone, or format on one side only.
• Promises in render are a smell. If you keep hitting this with async data, the answer is a data-fetching pattern (state, a query library, Suspense, or a Server Component) — not sprinkling await until it renders.

Whenever you see "objects are not valid as a React child," read it as: a JSX slot got an object; give it something printable instead. Reach into the property you meant (user.name), collapse double braces to single, format non-primitives into strings (date.toLocaleDateString()), resolve promises before rendering, map arrays of objects to elements with keys, and render error.message rather than the error. And when the value you're rendering came from the network, treat the error as a signal to check the response shape first — that is where the real fix almost always lives.