View Transitions API: Native Page Animations

Updated 8 October 2026.

The View Transitions API lets a browser animate between visual states. Use it to make a change of context easier to follow: opening an item, moving between related pages, or updating a view. Keep the underlying navigation and content usable when no transition runs.

Same-document and cross-document transitions

For a change inside one document, the browser can capture the old state, run your update, and animate into the new state. For navigation between documents, cross-document transitions can connect supported same-origin pages. The implementation differs; follow the browser platform’s same-document guide and cross-document guide.

Treat compatibility as something to test in your supported browsers. Do not make a transition API responsible for fetching content, deciding whether a link works, or handling a failed form submission.

A safe same-document pattern

Keep the DOM update in a function that works on its own. Feature detection and the motion preference decide whether to wrap it in a transition:

function updateView(updateDOM) {
  const reduced = matchMedia('(prefers-reduced-motion: reduce)').matches;
  if (!document.startViewTransition || reduced) {
    updateDOM();
    return;
  }
  return document.startViewTransition(updateDOM);
}

This helper assumes a synchronous DOM update. For asynchronous data, handle loading and failure explicitly and update only when the state you intend to show is ready. Preserve focus on a meaningful element after replacing interactive content.

Start small on a multi-page website

On compatible same-origin pages, a basic cross-document opt-in is:

@view-transition {
  navigation: auto;
}
@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(root),
  ::view-transition-new(root) {
    animation: none;
  }
}

The ordinary link should still navigate successfully without this CSS. Start with a short root transition before connecting individual elements across pages. Give shared elements intentional names and ensure there are no duplicate active names within a document.

Choose motion that explains the interaction

A restrained fade is often enough. A shared product image may be useful when it clearly connects a listing to the detail page. Avoid animating unrelated headings or moving the whole viewport a long distance simply because the feature permits it.

Keep important controls responsive during the transition. Test long titles, late-loading images, font changes and content that changes size between states. A transition should not conceal a layout problem or make an otherwise fast page feel slow.

Accessibility and navigation checks

• Verify the result with reduced motion enabled.
• Test keyboard focus before and after the change.
• Keep semantic headings, landmarks and link destinations intact.
• Check browser Back and Forward navigation.
• Test slow responses and failed content requests.
• Test a browser where the enhancement is unavailable.

For a larger animation system, coordinate ownership carefully. Two engines should not control the same element’s transform or opacity at the same time. Page transitions and scroll effects should each have a clear lifecycle and cleanup procedure.

Frequently asked questions

Does this replace a scrolling animation library?

No. View transitions connect visual states. A scroll animation system links effects to scrolling. Use either only where its behaviour helps the page.

Will an unsupported browser show a broken page?

It should show normal navigation or the normal DOM update. Feature detection and a working baseline are essential to that result.

Should every page use an elaborate transition?

No. Choose a consistent, modest effect, then add shared-element transitions only where they help a visitor understand where they moved.

Explore our frontend development services or discuss an accessible motion system.