Yes, and that is the whole point of the View Transitions API. It is a browser feature that animates between two states of a page, or between two separate pages, with a few lines of CSS. You no longer need a heavy animation library to make navigation feel smooth.
For years, smooth page transitions were a tradeoff. You either shipped a single page app with a router and an animation library, or you accepted the hard cut between pages that a normal website gives you. Neither option was free. One cost you performance, the other cost you polish.
The View Transitions API changes that tradeoff. It moves the work into the browser, where it belongs, and it lets a plain multi-page website animate like an app. That is a genuinely useful thing for the kind of marketing sites we build, so it is worth understanding properly.
It is a web platform API that captures a snapshot of the page before a change, captures the new state after the change, and animates between the two. MDN describes it as a mechanism for creating animated transitions between different website and element views, which reduces cognitive load and perceived loading time.
The browser does the hard part. It takes the old and new snapshots, works out which elements match, and generates the animation. You mostly just tell it which elements should be treated as the same thing across the change, using the CSS property view-transition-name.
Under the hood the browser exposes a set of pseudo-elements you can style, including ::view-transition, ::view-transition-group, ::view-transition-old, and ::view-transition-new. If you want a custom animation instead of the default crossfade, you target those with ordinary CSS animations.
Same-document transitions animate a change inside one page, like filtering a gallery or opening a detail panel. Cross-document transitions animate between two separate pages during a real navigation. The first is driven by JavaScript, the second by a CSS at-rule, and they have very different levels of browser support.
For the same-document case you wrap your DOM update in document.startViewTransition and pass it a callback. The browser snapshots the page, runs your callback, snapshots again, and animates the difference. There is also an element-scoped version for animating just one part of a page.
For the cross-document case you add the @view-transition at-rule to both pages and set navigation to auto. MDN notes that both documents must be on the same origin, and the navigation has to be same-origin with no cross-origin redirects. No JavaScript is required at all, which is the part that makes this interesting for regular websites.
Same-document transitions are safe to use. MDN lists Document.startViewTransition as Baseline Newly available since October 2025, meaning it works across the latest versions of the major browsers. Cross-document transitions are not there yet, and that gap matters for planning.
MDN currently marks the @view-transition at-rule as Limited availability, with the explicit note that the feature is not Baseline because it does not work in some of the most widely used browsers. That is the honest state of cross-document transitions today, whatever demos you may have seen.
The direction of travel is clear though. WebKit’s announcement of Interop 2026, published in February 2026, confirms that view transitions carry over as a focus area and that the scope now expands to include cross-document view transitions. Interop is the joint effort between browser vendors to close gaps like this one.
That same announcement gives useful numbers on where things stood. View transitions was already a focus area in Interop 2025, narrowly defined around same-document transitions and view-transition-class. Safari finished Interop 2025 with a score of 99.2 percent for view transitions, while the overall interoperability score across all areas sat at 90.8 percent.
For cross-document transitions, the minimum is one CSS block on both pages. You write the @view-transition at-rule, set navigation to auto, and the browser handles the default crossfade on navigation. To animate a specific element across the two pages, give it the same view-transition-name value on each.
The naming step is where the good version differs from the cheap version. If a card thumbnail on your listing page and the hero image on the detail page share a view-transition-name, the browser will morph one into the other. That single detail is what makes a site feel considered rather than just faded.
The rule to remember is that each view-transition-name has to be unique on the page at any one moment. Two visible elements sharing a name will break the transition. In practice that means generating the name per item, which is easy if your CMS gives each entry an ID or a slug.
After that, styling is normal CSS. You target the generated pseudo-elements and apply your own keyframes, easing, and durations. Because it is CSS, it runs on the compositor rather than in your JavaScript bundle, which is a meaningful difference for a site already fighting to keep its JavaScript bundle small.
Because it removes a reason to build a single page app. Many teams reach for a client-side router purely so navigation feels smooth. If the browser can animate between two static pages, you can keep the simpler architecture and still get the polish.
That matters more than it used to. Static pages are easier for crawlers to read, faster to deliver from a CDN, and far less likely to break when a script fails. Every animation library you do not ship is bytes the browser never has to download, parse, and run.
We wrote a fuller comparison of the two architectures in our piece on single page versus multi-page websites. Cross-document view transitions weaken one of the last strong arguments for the single page approach on a marketing site.
Not on their own. A transition does not make an offer more compelling or a form easier to finish. What it does is reduce the sense of waiting, because a moving connection between two states reads as faster than a hard cut, even when the load time is identical.
Our position is that transitions are a finishing touch, not a growth lever. We would never recommend delaying a launch for them, and we would never pitch them as a conversion fix. They belong in the same bucket as good typography: not the reason someone buys, but part of why the site feels trustworthy.
We looked at the wider evidence on this in our article on whether website animations help or hurt conversions. The short answer is that restrained motion helps and decorative motion usually does not.
Three things, mostly. Motion can make some users feel unwell, so you need to respect the prefers-reduced-motion media query and turn transitions off for anyone who has asked for less movement. Long transitions can also make a site feel slower rather than faster. And duplicate names silently break the effect.
The accessibility point is not optional. The prefers-reduced-motion media query exists precisely so people with vestibular conditions can opt out of movement, and honouring it is a few lines of CSS. Wrap your transition styles so they only apply when no reduction is requested.
On duration, our rule of thumb is to keep transitions short enough that nobody consciously notices them. If a visitor has time to think about the animation, it is too long. Fast navigation with a subtle transition beats slow navigation with a beautiful one every time.
Yes, through custom code. Webflow lets you add custom code in site settings and in individual page settings, so you can drop the @view-transition at-rule and your view-transition-name declarations in there. Nothing about the API requires a specific build tool or framework.
The practical catch is naming elements inside a Collection List. You need a unique view-transition-name per item, which usually means outputting the item slug into an inline style or a data attribute and generating the CSS from it. It is fiddly but it is not hard.
If you are working this way, keep the custom code tidy and documented, because the next person to open the project will not expect it. The custom code panel is the right home for it, and keeping that panel tidy is what makes the build maintainable later.
Use same-document transitions freely, since they are Baseline and safe. Treat cross-document transitions as progressive enhancement: add them, let them work where supported, and accept a normal page load everywhere else. Nothing breaks in browsers that do not support the at-rule, because they simply ignore it.
That is the whole reason this is a low risk feature to adopt early. It fails quietly. A visitor on an unsupported browser gets exactly the site they would have had anyway, and a visitor on a supported one gets something nicer. This is progressive enhancement working the way it is supposed to.
If you are weighing up whether it is worth the effort on your own site, or you want a view on where your build would actually benefit from it, we’re happy to talk it through. Reach out at phoenix.studio and we’ll give you an honest read.
Tell us where you want to go. We'll tell you how we'd get you there.