React 19.3: stable View Transitions and Trusted Types

React 19.3 landed on npm on September 9, 2026. It's a minor release with no breaking changes, so the upgrade itself is boring in the good way. What matters is what came out of the experimental drawer. View Transitions and Fragment Refs are now stable, and two smaller additions, use(browser()) and Trusted Types support, quietly change how you think about rendering and security.

We read the release notes so you can skip the hype and get to the parts that touch real projects.

What actually shipped

View Transitions sat behind an experimental flag for about a year and a half. Now the <ViewTransition> component is stable. It animates elements as they enter, exit, move, or resize, and it hooks into the browser's View Transition API alongside startTransition, Suspense, and useDeferredValue. A companion helper, addTransitionType(), lets you vary the animation based on what caused the transition, like "next" versus "previous" on a carousel.

Fragment Refs are stable too. You can attach a ref to a <Fragment> and get back a limited set of DOM methods for the whole group of children: addEventListener, focus(), observeUsing() for IntersectionObserver, plus a few measurement helpers. If you have ever rendered a list of siblings and then fought React to attach one observer across all of them, this is the fix.

Then two things that got less attention but deserve more.

use(browser()) is a new opt-out from server rendering. Call it inside a component and React suspends that component on the server, shows the Suspense fallback in the initial HTML, then renders it normally after hydration. It's meant for components that genuinely cannot run on the server, like anything reading localStorage or the user's timezone.

Trusted Types support is the one we care about most. React DOM used to coerce every value to a string before handing it to the DOM. Now it passes TrustedHTML, TrustedScript, and TrustedScriptURL through untouched, so you can run React under a Content Security Policy with require-trusted-types-for 'script' and get DOM-based XSS protection at the platform level.

Our take

Start with the security win. During pentesting engagements we still find DOM-based XSS more often than teams expect, usually through a dangerouslySetInnerHTML call that trusts data it shouldn't. Trusted Types moves the check into the browser. If a value hasn't been through a Trusted Types policy, the assignment throws instead of executing. That is the kind of defense that holds even when a developer slips up later. When we configure Cloudflare and CSP for clients, this is the layered control we push for, and now React stops fighting it.

The catch is that Trusted Types only helps if you turn it on. React 19.3 makes React compatible. It does not set the CSP header for you. Our advice for this week is concrete. Add require-trusted-types-for 'script' in report-only mode, ship it, and watch the violation reports for a couple of weeks before you enforce. You will find the sinks you forgot about without breaking production.

Be careful with use(browser()). It's a clean API, but it means the component's content is absent from the server-rendered HTML. For a settings widget, fine. For anything a search engine or a social scraper needs to see, that content is now invisible on first paint. We have watched teams hurt their own SEO by pushing too much rendering to the client. Use it for browser-only leaf components, not for content that matters to crawlers.

Mobile teams, wait a beat. View Transitions only work in the DOM right now. The React team says React Native support is in progress, but it is not here yet. In our native iOS and Android work we lean on the platform's own transition APIs anyway, and for React Native projects we would hold off designing around <ViewTransition> until it actually ships for the platform. Don't build a shared animation layer on an API that lives on one target.

One thing to do now

Pick your smallest React app, upgrade to 19.3 on a branch, and turn on Trusted Types in report-only mode. It's a low-risk way to see how much unsafe DOM work is hiding in your codebase, and the upgrade has no breaking changes to slow you down. If the report comes back clean, good. If it doesn't, you just found next sprint's security backlog.

If shipping fast without leaving XSS holes behind sounds familiar, let's talk. We do this for web and mobile teams every week, from cloud-native builds to security reviews.