# Native page animations in the browser: View Transitions go Baseline
Table of Contents
Changing the view on a website is almost always an abrupt jump: one piece of content disappears, another shows up, with no smooth handoff in between. To get the kind of fluid animations you see in apps - an image growing into place, a list sliding in tidily - you usually need dedicated JavaScript libraries, with code to write and maintain. In mid-October 2025 something changed for people who build websites: same-document View Transitions, meaning animated transitions within the same page, became Baseline. In plain terms, they now work reliably across all the major browsers, and most of the work is done by the browser itself.
The news in brief
On 14 October 2025, same-document View Transitions reached “Baseline Newly available” status. The shift happened when Firefox 144 shipped, the last of the three main browser engines to support the feature. Google Chrome has offered it since 2023 (from version 111), and Apple’s Safari since version 18, released in September 2024. With Firefox on board, the circle closes: the same feature, written once, behaves the same everywhere. This milestone is part of Interop 2025, the initiative through which browser makers agree on a list of web features to make work consistently across engines over the course of the year.
What “Baseline” means
Baseline is a label built to answer a practical question: can I use this feature without worrying that I’ll leave out a slice of my visitors? A feature is Baseline when it’s supported by the recent versions of browsers built on the three most common engines: Chromium (Chrome, Edge, and others), WebKit (Safari), and Gecko (Firefox).
The “Newly available” status means the milestone has only just been reached: the feature is ready to use, but older devices may still run browser versions without support. Over time, as updates spread, the status moves to “Widely available.” Knowing that a feature is Baseline helps you decide, with some confidence, whether to adopt it in a real project.
What a view transition is
A view transition is an animation that connects two states of a page. Picture a photo gallery: you tap a thumbnail and watch it grow into the full-size image, instead of it popping in all at once. Until recently, an effect like that had to be built by hand.
From the browser’s point of view, the mechanism is easy to describe. When a transition starts, the browser takes a “photograph” of the page as it is now, lets the content change, takes a second photograph of the new state, and animates the move from the first to the second. The default effect is a cross-fade: the old look fades out as the new one appears. With a few lines of CSS you can then get more elaborate motion, such as a slide or a zoom.
October’s news concerns same-document transitions, the ones that happen without leaving the page, while the content is updated via JavaScript. This is the typical scenario for single-page applications, where the site rewrites parts of the screen without reloading everything. There’s also a cross-document variant, meant for transitions between different pages during ordinary navigation: it’s a related but separate feature, on its own track, and it isn’t the subject of this announcement.
The problem it solves
Until now, animating the move between two states nicely almost always called for specialized JavaScript libraries, much like positioning tooltips and menus used to before CSS Anchor Positioning. These are capable tools, but they come at a cost: extra code to load and maintain, animations to sync by hand, and the risk of weighing the page down. There’s a consistency angle too, since every library does things its own way.
By moving this work into the browser, much of that code is no longer needed. The browser knows the position and appearance of elements before and after the change, so it can work out the animation efficiently. For many common cases you get a pleasant transition without adding any library at all, with an indirect benefit for how responsive the page feels to interactions too, the same thing INP measures.
How it works, in practice
The heart of the feature is a single method, document.startViewTransition(). You hand it the function that changes the page content, and the browser takes care of the animation.
// Update with no animationfunction updatePage() { // ... this is where the page content changes ...}
// With an animated transition, when the browser supports itfunction updateWithTransition() { if (!document.startViewTransition) { updatePage(); // fallback: just update return; } document.startViewTransition(() => updatePage());}The key part is the if (!document.startViewTransition) check: if the browser doesn’t know the feature, the content still updates, just without the animation. This approach, called progressive enhancement, keeps the site fully working everywhere, with the animation as a bonus where it’s available.
To animate a single element independently from the rest - for example to make an image “travel” from the thumbnail to its large version - you give it a name through the CSS property view-transition-name. The browser recognizes that the element is the same before and after the change, and animates it accordingly, rather than settling for the general cross-fade.
What changes for frontend developers, and a couple of caveats
For anyone building interfaces, the main upside is less code to write for a smoother result. Two details are still worth keeping in mind.
The first concerns Firefox: its first version with this feature doesn’t yet include so-called view transition types, a more advanced tool for applying different animations depending on context. If you need them, you can plan a fallback, exactly like the check shown above.
The second is accessibility. Not everyone welcomes animation, and some people find it distracting or uncomfortable. Operating systems offer a setting to reduce motion, which on the web is read through the CSS prefers-reduced-motion rule. It’s good practice to respect it, dialing the animation down or off for anyone who asked for less movement.
In short
Same-document View Transitions became Baseline on 14 October 2025, when support landed in Firefox 144 alongside Chrome and Safari. In practice, the browser can now animate the move between two states of a page on its own, a job that used to call for JavaScript libraries almost every time, much like other capabilities now shipping natively in the browser, such as AI running right there inside it. For people building sites it means less code, more consistent animations, and potentially lighter pages, as long as you handle older browsers and reduced-motion preferences with care. It’s one of those quiet changes that, over time, make the web a little more pleasant to use.
