Go back

View Transitions Are Finally Universal: Firefox 144 Changes Everything

Oct 19, 2025

Firefox 144 just shipped View Transition API support. After years of Chrome exclusivity, seamless page transitions are now cross-browser. Learn the basics and why this matters now.

View Transitions

Firefox 144 Just Made View Transitions Universal

On October 14, 2025, Mozilla shipped Firefox 144 with full support for the View Transition API. This is a big deal.

For the past two years, View Transitions have been a Chrome-only feature. If you wanted smooth, native-feeling page transitions on the web, you either shipped a Chrome-only experience or built complex animation libraries that never quite felt right.

That constraint just disappeared.

Chrome, Edge, Safari, and now Firefox all support the View Transition API. This means you can ship polished, app-like transitions that work for basically everyone. The holdout browsers are gone.

If you've been waiting for cross-browser support before investing in View Transitions, that time is now.

What View Transitions Actually Do

The View Transition API lets you animate between different states of your website smoothly. Instead of pages abruptly changing, elements morph, fade, and slide into their new positions.

Think about how native mobile apps transition between screens. That's what this enables for the web.

Two main use cases:

  1. Single-page apps (SPAs) - Animate between different DOM states within the same page
  2. Multi-page apps (MPAs) - Animate navigation between completely different HTML documents

Historically, SPAs could hack together transitions with lots of JavaScript. MPAs had no real solution at all. The View Transition API makes both trivial.

How This Blog Uses View Transitions

On this site, when you click a blog post from the main list, the title smoothly transitions from its position in the list to the top of the article page.

It's a simple effect, but it creates continuity. Your brain tracks the element as it moves, making the navigation feel instant even though a new page is loading.

Here's the actual code powering that transition:

/* Mark which elements should transition */
.post-title {
  view-transition-name: post-title;
}

/* The browser handles the rest automatically */

That's it. No JavaScript animation libraries. No complex state management. The browser does the heavy lifting.

The Basics: Your First View Transition

The simplest possible implementation for a single-page app:

// Without View Transition - instant, jarring change
function updateView() {
  document.querySelector('.content').innerHTML = newContent;
}

// With View Transition - smooth, polished
function updateView() {
  document.startViewTransition(() => {
    document.querySelector('.content').innerHTML = newContent;
  });
}

The browser automatically:

  1. Takes a snapshot of the current state
  2. Executes your DOM update
  3. Takes a snapshot of the new state
  4. Animates between them with a crossfade

No animation code required.

Targeting Specific Elements

The default crossfade is fine, but you probably want specific elements to transition in specific ways.

/* Give elements unique transition names */
.hero-image {
  view-transition-name: hero;
}

.article-title {
  view-transition-name: title;
}

.main-content {
  view-transition-name: content;
}

Now when the view updates:

  • The hero image morphs to its new position/size
  • The title slides to where it needs to go
  • Content fades in/out independently

The browser tracks elements by their view-transition-name and creates smooth animations between old and new positions.

Important: Each view-transition-name must be unique on the page. Think of them as IDs for the animation system.

Multi-Page Transitions (The New Part)

Single-page transitions have been possible with JavaScript trickery for years. Multi-page transitions were impossible.

Until now.

To enable transitions between different HTML documents:

/* In your global CSS */
@view-transition {
  navigation: auto;
}

That's it. Now navigations between pages will transition instead of instantly replacing content.

For elements that appear on multiple pages (like a persistent header or navigation), give them the same view-transition-name:

/* In your site-wide CSS */
.site-header {
  view-transition-name: header;
}

.page-title {
  view-transition-name: title;
}

When navigating from /posts to /posts/some-article, any element with matching transition names will smoothly morph between pages.

This is what powers the title transition on this blog. The post title on the list page and the article page share the same view-transition-name, so the browser animates between them during navigation.

How It Works Behind the Scenes

When you trigger a view transition, here's what actually happens:

1. Capture Phase The browser takes screenshots of elements marked with view-transition-name. Each named element gets its own snapshot, capturing position, size, and visual appearance.

2. Update Phase Your DOM update executes. This is where the actual state change happens - new content loads, elements move, styles change.

3. Animation Phase The browser takes new snapshots of the updated state, then generates a pseudo-element tree:

::view-transition
├─ ::view-transition-group(name)
│  ├─ ::view-transition-image-pair(name)
│  │  ├─ ::view-transition-old(name)
│  │  └─ ::view-transition-new(name)

The old snapshot fades out while the new snapshot fades in. Position and size changes are smoothly interpolated.

You can customize these animations by targeting the pseudo-elements:

/* Make the title slide in from the right */
::view-transition-old(title) {
  animation: slide-out-left 0.3s ease-out;
}

::view-transition-new(title) {
  animation: slide-in-right 0.3s ease-out;
}

But the defaults are good enough for most use cases.

Why This Matters Now

Browser support crossed the threshold where you can actually ship this to production:

  • Chrome/Edge: Supported since version 111 (March 2023)
  • Safari: Supported since version 18 (September 2024)
  • Firefox: Supported since version 144 (October 2025)

That's 95%+ of web users.

For the remaining browsers, the API degrades gracefully. If View Transitions aren't supported, the callback in document.startViewTransition() still executes - users just get instant updates instead of animated ones.

// Works everywhere, transitions where supported
if (document.startViewTransition) {
  document.startViewTransition(() => updateDOM());
} else {
  updateDOM();
}

Performance Considerations

View Transitions are fast. The browser handles everything at the compositor level, which means:

  • Animations run at 60fps even on modest hardware
  • No JavaScript execution during the animation
  • Works well with Interaction to Next Paint (INP) metrics

The biggest cost is the snapshot phase. The browser needs to capture pixels for each transitioning element. For 5-10 elements, this is negligible. For 100 elements, it might cause jank.

Rule of thumb: Keep the number of unique view-transition-name elements under 20 for smooth performance.

The Strategic Window

Right now, most websites don't use View Transitions. This creates a noticeable quality gap.

Sites with transitions feel premium and polished. Sites without them feel dated in comparison. The difference is subtle but real - users perceive transitioning sites as faster and more refined.

As Firefox 144 rolls out over the next few months, View Transitions will go from "nice Chrome feature" to "table stakes for modern web UX."

Companies shipping this now establish a quality bar before it becomes expected. Companies waiting will be playing catch-up.

The implementation effort is low. The impact on perceived quality is high. That's a rare combination.

Getting Started Today

If you're building a single-page app with React, Vue, or Svelte, wrap your state updates:

function navigate(newRoute) {
  document.startViewTransition(() => {
    // Your routing logic here
    router.push(newRoute);
  });
}

If you're building a multi-page app, add the CSS opt-in and mark your persistent elements:

@view-transition {
  navigation: auto;
}

.header { view-transition-name: header; }
.logo { view-transition-name: logo; }

Start simple. Add transitions to navigation. Then gradually expand to other state changes.

The API is forgiving - if you mess up the names or structure, the worst that happens is no transition. The page still works.

What's Next

The View Transition API is still evolving. Upcoming features include:

  • Transition types - Different animations for different navigation patterns
  • Nested transitions - Coordinated animations across component boundaries
  • Gesture-driven transitions - Swipe to navigate with physics-based animations

But the core API is stable and shipping in all major browsers. What's available today is enough to significantly upgrade your UX.

The constraint was browser support. Firefox 144 removed that constraint.

If you've been waiting to try View Transitions, this is the moment.

Summary

Firefox 144 shipped View Transition API support in October 2025, completing cross-browser coverage. Chrome, Safari, Edge, and Firefox all support the API now.

View Transitions let you animate between page states with minimal code. The browser handles the complexity - you just mark which elements should transition and provide the DOM update.

This blog uses View Transitions for title morphing between the post list and article pages. It's a basic example, but it demonstrates how little code is needed for polished results.

The API works by capturing snapshots, applying your DOM changes, then animating between old and new states. You can customize the animations, but the defaults are production-ready.

With universal browser support, there's no reason to wait. Small implementation effort, significant perceived quality improvement.

Start with navigation transitions. Expand from there.

The window to differentiate on polish is narrow. Firefox 144 just made View Transitions universal.

Position accordingly.