The View Transitions API: App-Like Page Changes on Plain Sites

The polish gap between websites and apps

Click a link on a typical website and the page blinks: a flash of white, a repaint, and the new page appears. Native apps never do this; screens slide and elements glide into place, which is a large part of why apps feel more expensive. The View Transitions API brings that continuity to ordinary websites, and since cross-document support arrived in browsers, it works between separate pages of a normal multi-page site, not just inside single-page applications.

This is not a framework feature. A plain HTML site, a WordPress theme or a static site generator can all use it, and the minimum viable version is a few lines of CSS.

Perceived speed matters commercially, too. Smooth transitions make navigation feel faster even when load times are unchanged, they hold attention between pages, and they make a small firm's website feel considered. It is the digital equivalent of a well-fitted shop door instead of one that slams.

Turn it on with a few lines of CSS

Cross-document view transitions activate when both the outgoing and the incoming page opt in. Add this to the stylesheet that every page shares: @view-transition { navigation: auto; }. That single rule tells the browser to snapshot the old page, load the new one, and animate between them, a quick cross-fade by default, whenever a user navigates between pages on the same origin. Third-party destinations are unaffected.

You can customise the default with standard CSS animations targeting the transition pseudo-elements. ::view-transition-old(root) and ::view-transition-new(root) represent the outgoing and incoming snapshots, and you can assign them keyframes to create slides, zooms or longer fades. Keep durations short, somewhere around 200 to 300 milliseconds, or the site starts to feel slower rather than smoother.

There is also a JavaScript API, document.startViewTransition(), used mainly by single-page applications to wrap DOM updates. For a normal multi-page site you rarely need it; the CSS opt-in covers standard navigation, which keeps the implementation honest and light.

Morphing elements between pages

The effect that makes people ask how you did it is the shared-element morph: a product thumbnail on a listing page that grows into the hero image on the product page. You get it by giving the element the same view-transition-name on both pages, for instance view-transition-name: product-photo on the thumbnail and on the detail image. The browser matches the two by name and animates position, size and shape between them.

Names must be unique within a page, so for repeating cards you set names dynamically, with a one-line bit of JavaScript or a templating variable such as product-photo-{id}. Good candidates for morphs include:

• Product or portfolio images, from grid card to detail hero.
• Article headlines, from listing link to page title.
• The site logo, so it holds still while everything else changes.
• Profile or team photos moving between listing and biography pages.

Start with exactly one morphing element per journey. The root cross-fade plus a single shared element already delivers most of the perceived quality.

Browser support and safe fallbacks

Same-document view transitions have been in Chrome and Edge since 2023 and in Safari since version 18; cross-document transitions followed in Chrome and Edge in 2024 and in Safari 18.2. Firefox shipped same-document support in 2025, with cross-document support slower to land, so check caniuse.com for the current position rather than assuming.

The best part is the failure mode: browsers that do not understand @view-transition simply perform a normal navigation. There is nothing to polyfill and no error state, which makes this one of the safest progressive enhancements you can ship. You can verify behaviour in Chrome DevTools, where the Animations panel lets you slow transitions down and inspect the pseudo-element tree.

One accessibility duty comes with it. Some users experience motion sickness from animation and set prefers-reduced-motion on their device, so respect that: keep only the subtle default, or disable transitions entirely, inside an @media (prefers-reduced-motion: reduce) block.

Pitfalls that make transitions feel worse

The API is simple; taste is the hard part. The common mistakes are all avoidable:

• Duplicate names. Two elements sharing a view-transition-name on the same page cause the transition to be skipped, and it fails silently.
• Slow servers. The animation cannot hide a two-second response; cross-page transitions reward sites that are already quick.
• Morphing wildly different shapes. A tiny thumbnail morphing into a full-bleed banner can distort; keep aspect ratios similar.
• Animating everything. One or two named elements per page reads as polish; six reads as chaos.
• Forgetting back and forward. Test browser history navigation, and note that you can style reverse transitions differently if a journey needs it.

A 30-minute implementation plan

Here is a realistic plan for an existing multi-page site:

• 1. Add @view-transition { navigation: auto; } to your global stylesheet and confirm the cross-fade in Chrome.
• 2. Pick one high-traffic journey, such as blog listing to article, and add matching view-transition-name values to the title or image.
• 3. Shorten or customise the default animation with the transition pseudo-elements if the fade feels slow.
• 4. Add the prefers-reduced-motion guard.
• 5. Test in Safari, Firefox and an older browser to confirm graceful fallback, then ship.

For a few lines of CSS, your site gains the kind of finish visitors associate with well-funded apps, and measured against the effort, few frontend upgrades return as much perceived quality per hour of work. If you would like this level of polish designed into your next site, our team at Thind Global Services can help.