Power Your Software Testing with AI Agents and Cloud
The Native AI-Agentic Cloud Platform to Supercharge Quality Engineering. Test Intelligently and Ship Faster.
- TestMu AI (Formerly LambdaTest)
- /
- Learning Hub
- /
- View Transitions API: Browser Support, Features, Limits
View Transitions API: Browser Support, Features, Limits
View Transitions API works in Chrome 111+, Edge 111+, Opera 97+, Samsung Internet 23+, Safari 18+, and Firefox 144+. Learn features, use cases, and limits.
Published on:
On This Page
The View Transitions API is a W3C web standard that lets a page animate changes between DOM states in a single document or across two same-origin documents. It works in Chrome 111+, Edge 111+, Opera 97+, Samsung Internet 23+, Safari 18+, and Firefox 144+, while Internet Explorer never supported it.
This guide covers what the View Transitions API is, the browsers that support it, the key features, the difference between same-document and cross-document transitions, the use cases, and the known issues.
What is the View Transitions API?
The View Transitions API is a JavaScript and CSS web platform feature that snapshots the page before and after a DOM update and animates the difference. The W3C CSS Working Group defines the spec. document.startViewTransition starts the animation, and CSS pseudo-elements like ::view-transition-group customize each named region.
Which browsers does the View Transitions API support?
The View Transitions API works on every modern engine. Same-document transitions ship in Chromium browsers from Chrome 111, in WebKit from Safari 18, and in Gecko from Firefox 144. Cross-document transitions ship in Chromium from Chrome 126, while Firefox and Safari do not yet support them.
View Transitions API compatibility in Chrome
Chrome supports same-document view transitions from Chrome 111 on Windows, macOS, Linux, ChromeOS, and Android, and cross-document view transitions from Chrome 126. Chrome 4 to 110 did not support the API. Chrome for Android picks up the same Blink build, so phones on Chrome 111+ animate alongside desktop.
View Transitions API compatibility in Edge
Edge supports same-document view transitions from Edge 111 on Windows, macOS, Linux, and Android, and cross-document view transitions from Edge 126. Edge 12 to 110 did not support the API. Chromium-based Edge tracks Blink, so every Edge channel that follows the stable Chromium milestone gets View Transitions on the same schedule.
View Transitions API compatibility in Firefox
Firefox supports same-document view transitions from Firefox 144 on Windows, macOS, Linux, and Android. Firefox 143 ships the code behind the dom.viewTransitions.enabled flag, and Firefox 2 to 142 do not support the API at all. Firefox does not yet support cross-document view transitions or view transition types.
View Transitions API compatibility in Safari
Safari supports same-document view transitions from Safari 18 on macOS, iPadOS, and iOS. Safari 18.2 added view-transition-name: auto, and Safari 18.4 added view-transition-name: match-element. Safari 3.1 to 17.6 on macOS and iOS 3.2 to 17.7 do not support the API. Safari has not shipped cross-document view transitions yet.
View Transitions API compatibility in Opera
Opera supports same-document view transitions from Opera 97 on Windows, macOS, Linux, and Android, and cross-document view transitions from Opera 112. Opera 9 to 96 did not support the API. Opera Mobile picked it up from Opera Mobile 80, and the Chromium-based Opera and Opera GX channels ship the feature without a flag.
View Transitions API compatibility in Samsung Internet
Samsung Internet supports same-document view transitions from Samsung Internet 23 on Galaxy phones running Android 9 or later. Samsung Internet 4 to 22 did not support the API. Samsung Internet tracks the Chromium pipeline, so cross-document view transitions land on the same channel that already runs Chrome 126+ Blink.
View Transitions API compatibility in Android Browser
The legacy stock Android Browser supports same-document view transitions from Android Browser 147. Earlier Android Browser releases did not support the API. Chrome for Android 111+, the modern Android WebView 111+, and Firefox for Android 144+ also support the API on every supported Android version.
View Transitions API compatibility in Internet Explorer
Internet Explorer does not support the View Transitions API in any version, from IE 5.5 to IE 11. The Trident engine has been frozen, so the feature will never reach IE. Microsoft has retired Internet Explorer, so move View Transitions work to Chromium-based Edge, which has supported the API since Edge 111.
Note: The View Transitions API still has gaps across Firefox cross-document support, Safari pre-18, and older Samsung Internet builds. Test it on real browsers and OS with TestMu AI. Try TestMu AI free!
What are the key features of the View Transitions API?
The View Transitions API exposes one JavaScript entry point and a small CSS surface that together drive the animation. The browser handles snapshotting, layout, and tweening, so most pages need only a few lines of code.
- document.startViewTransition: The single JavaScript entry point. It accepts a callback that mutates the DOM and returns a ViewTransition object with ready, finished, and updateCallbackDone promises.
- view-transition-name CSS property: Names an element so the browser captures it separately from the page root. Two elements that share the name morph into each other across the transition.
- ::view-transition pseudo-elements: ::view-transition, ::view-transition-group(name), ::view-transition-image-pair(name), ::view-transition-old(name), and ::view-transition-new(name) target the snapshot tree from CSS.
- @view-transition at-rule: Opts a same-origin document in to cross-document transitions with navigation: auto. Both the source and destination pages must include the at-rule for the navigation to animate.
- view-transition-class: Lets one transition group inherit styles from a class, so a list of cards can share one set of @keyframes without naming every card individually. Available in Chromium 125+ and Safari 18.4+.
- View transition types: ViewTransition.types is a set-like object that flags a transition as forward, back, or any custom string the page picks. CSS uses :active-view-transition-type to branch on the value. Firefox 144 does not yet ship types.
- PageRevealEvent and PageSwapEvent: Fire on the destination and source documents during a cross-document navigation, so each side can tag the active types or skip the animation.
Paste this snippet into the DevTools console of any modern browser. The expression checks for document.startViewTransition before calling it, runs a real DOM mutation that toggles a dark class on the body, and falls through to a plain class toggle on browsers that do not support the API.
// Paste this into the DevTools console of any modern browser.
if (typeof document.startViewTransition === "function") {
console.log("View Transitions API is available.");
// Animate a real DOM change. Toggling a class on <body> is enough.
document.startViewTransition(() => {
document.body.classList.toggle("dark");
});
} else {
console.log("View Transitions API is not supported. Falling back.");
document.body.classList.toggle("dark");
}Same-document vs cross-document view transitions
Same-document view transitions animate a DOM change inside one page, typically a single-page app. Cross-document view transitions animate the navigation from one HTML document to another on the same origin, typically a multi-page app. Each path uses a different entry point and ships in a different set of browsers.
| Dimension | Same-document | Cross-document |
|---|---|---|
| Entry point | document.startViewTransition(callback) | @view-transition { navigation: auto; } |
| Typical app shape | Single-page app, route swap inside one document | Multi-page app, real navigation between two documents |
| Chromium support | Chrome 111+, Edge 111+, Opera 97+ | Chrome 126+, Edge 126+, Opera 112+ |
| Safari support | Safari 18+ on macOS, iPadOS, iOS | Not yet supported |
| Firefox support | Firefox 144+ on desktop and Android | Not yet supported |
| Origin rule | Single document, no origin check | Same-origin only, both pages must opt in |
| Lifecycle events | ViewTransition.ready and finished promises | PageRevealEvent and PageSwapEvent |
What are the use cases of the View Transitions API?
Production apps use View Transitions to make state changes feel like a fluid handoff instead of a hard cut. The API replaces hand-rolled FLIP animations and library-based page transitions for most common UI patterns.
- Single-page app route changes: Astro View Transitions, Next.js App Router, and React Router wrap route swaps in document.startViewTransition so an SPA gets a smooth fade or slide between routes.
- Image gallery and detail views: A grid thumbnail with view-transition-name: hero morphs into the full-size hero image on the detail page, the same pattern Pinterest, Unsplash, and Apple Music style use.
- List reorders and sortable tables: A sortable table or kanban board names each row with a stable view-transition-name and the rows slide into their new positions on sort or drag-end.
- Dark mode and theme toggles: Toggling a theme class inside startViewTransition gives the color change a circular reveal centered on the toggle button, the pattern Chrome and many design systems demo.
- Modal, dialog, and side-panel transitions: Wrapping the open and close state changes in startViewTransition animates the panel slide-in without a third-party motion library.
- Cross-document MPA navigation: A documentation site or e-commerce flow opts both pages in with @view-transition and the back-forward navigation animates without a client-side router.
- Progressive disclosure flows: A multi-step checkout or onboarding tags forward and back as view transition types, so CSS branches on :active-view-transition-type for directional slide animations.
What are the known issues with the View Transitions API?
The View Transitions API is now Baseline for same-document flows, so most rough edges show up around cross-document support, name collisions, and accessibility rather than browser gaps.
- Cross-document gap on Firefox and Safari: @view-transition only animates in Chromium today. Firefox 144 and Safari 18 ignore the at-rule, so an MPA flow snaps without animation on those engines until they ship the feature.
- Duplicate view-transition-name throws: Two visible elements that share a view-transition-name throw and skip the transition. Run a uniqueness check during state changes, or scope names with the element id.
- Long-running JavaScript blocks the snapshot: startViewTransition waits for the callback to resolve before snapshotting. A heavy synchronous DOM update or a slow fetch leaves the page frozen on the old snapshot until the callback returns.
- prefers-reduced-motion still needs manual handling: The browser does not skip the transition automatically. Wrap the call in a matchMedia('(prefers-reduced-motion: reduce)') check so screen-reader and vestibular-sensitive users do not animate by default.
- Iframes are isolated: A view transition inside an iframe does not extend to the parent document, and a parent transition does not paint into a child iframe. Plan layout so the transition stays in one frame.
- Firefox 144 does not ship view transition types: ViewTransition.types and :active-view-transition-type CSS branching are not yet in Firefox. Feature-detect with 'types' in transition before relying on the property.
- Safari swipe-back used to interrupt transitions: Earlier Safari 18 builds let a back-swipe gesture continue a running transition. Safari 18.2 fixed the bug, but on stale iOS 18.0 and 18.1 devices the behavior still appears.
- Focus management is your job: The API animates pixels, not focus. Keyboard focus stays on the old element unless the page calls element.focus() inside the startViewTransition callback.
In my experience, the trap that bites every first View Transitions integration is the duplicate-name throw. A grid of cards or a list of avatars renders fine until two visible items end up with the same view-transition-name, and the whole transition skips with a console error. Generate the name from a stable id during render and the entire class of bugs disappears.
Citations
All View Transitions API version numbers and platform notes in this guide come from these primary sources:
- MDN Web Docs - View Transition API: developer.mozilla.org/en-US/docs/Web/API/View_Transition_API
- MDN Web Docs - ViewTransition interface: developer.mozilla.org/en-US/docs/Web/API/ViewTransition
- MDN Web Docs - Document.startViewTransition: developer.mozilla.org/en-US/docs/Web/API/Document/startViewTransition
- MDN Web Docs - view-transition-name CSS property: developer.mozilla.org/en-US/docs/Web/CSS/view-transition-name
- MDN Web Docs - @view-transition at-rule: developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
- W3C CSS View Transitions Module Level 1: w3.org/TR/css-view-transitions-1
- W3C CSS View Transitions Module Level 2: w3.org/TR/css-view-transitions-2
- Chrome for Developers - View Transitions: developer.chrome.com/docs/web-platform/view-transitions
- web.dev - Same-document view transitions Baseline: web.dev/blog/same-document-view-transitions-are-now-baseline-newly-available
- WebKit blog - Safari 18 View Transitions: webkit.org/blog/15443/news-from-wwdc-webkit-features-in-safari-18-beta
- MDN Web Docs - Firefox 144 for developers: developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/144
- React documentation - ViewTransition component: react.dev/reference/react/ViewTransition
Author
Prince Dewani
Blogs: 28
Prince Dewani is a Community Contributor at TestMu AI specializing in AI agents, software testing, QA, and SEO. He is certified in Selenium, Cypress, Playwright, Appium, Automation Testing, and KaneAI, and presented academic research on AI agents at PBCON-01. At TestMu AI, he has also carried out extensive cross-browser research on the support of modern web technologies such as WebGPU, WebAssembly, WebXR, WebGL2 and other web technologies, validating their compatibility and feature parity across major browsers and rendering engines through rigorous hands-on testing. Prince has hands-on experience building AI agent workflows using Anthropic Claude, Google Antigravity, n8n, LangChain, and other agentic frameworks, and works regularly with MCP and A2A protocols. He shares his work with 5,500+ QA engineers, developers, DevOps experts, tech leaders, and AI agent practitioners on LinkedIn.
Frequently asked questions
Did you find this page helpful?
More Related Blogs
TestMu AI forEnterprise
Get access to solutions built on Enterprise
grade security, privacy, & compliance
- Advanced access controls
- Advanced data retention rules
- Advanced Local Testing
- Premium Support options
- Early access to beta features
- Private Slack Channel
- Unlimited Manual Accessibility DevTools Tests