How to Add Creative Page Transitions to Framer Projects
By
A. Rishad
Founder @framerstacks
800+ section & components
Components every week
50+ Custom forms
Complete UI kit
CMS collection
Premium templates
One-time payment starts from
Sign in, if you already have an account.
Have questions? Contact us
If you've searched "how to add page transitions in Framer," you've probably already found out the hard way that Framer doesn't have one built in. There's a page-load fade you can turn on in Site Settings, but the moment you want something more deliberate, a curtain wipe, a circle reveal, anything that feels like a real between-pages moment, you're on your own.
I went down this road myself while building out Framerstacks. What follows is what I learned: why Framer's architecture makes this harder than it looks, where the DIY attempts quietly fall apart, and the checklist I ended up using to build a version that actually holds up in production.
Why Framer doesn't have native page transitions
Every page in a Framer site is, structurally, its own document. When a visitor clicks a link to another page, the browser is (in most cases) loading a fresh page, not swapping out a section of an already-running app the way a single-page React app would.
That's great for performance and simplicity, but it means there's no shared "parent" component sitting above every page that could hold a transition animation and orchestrate it across the click.
The built-in "Fade in" option you'll find in Site Settings is really just an entrance animation on the page you're landing on. It has no idea what page you came from, so it can't do an exit animation, and it can't coordinate anything more elaborate than a fade.
The DIY approach (and where it quietly breaks)
The obvious fix is a code override: intercept the click, cover the screen with an animated overlay, then navigate. It works the first time you test it. Then it breaks in ways that don't show up until real visitors hit them.
First crack: it works live but not in Framer Preview. Preview runs your site inside an iframe and navigates with the History API, no full reload. A transition built around location.assign() paints a black screen in Preview and never resolves, because Preview never does the hard reload the code is waiting for.
Second crack: external links, new tabs, and downloads get hijacked. A naive click-listener intercepts every link on the page, including mailto:, tel:, Cmd/Ctrl-click, and links meant to open in a new tab. Visitors lose browser behavior they take for granted.
Third crack: rapid clicks and the Back button break the animation state. Click two links fast, or hit Back mid-transition, and the overlay can get stuck covering the screen with no way to dismiss it.
None of this shows up in a five-minute test. It shows up a week later, in a message from a client asking why their site "went black."
What a reliable page transition system actually needs
After running into every one of those problems, I started judging any transition setup, mine or anyone else's, against one question: does it hold up in production, not just in a demo?
It has to behave the same in Preview and on the published site. If it only works after you publish, you can't confidently test changes before they go live.
It has to know the difference between your own pages and everything else. Same-origin detection isn't optional; it's the line between a nice effect and a broken external link.
It has to leave new-tab clicks, downloads, and modifier-key clicks alone entirely. And if the animation ever stalls, for any reason, navigation still has to complete. A visitor should never be staring at a stuck overlay wondering if the site crashed.
One more: reduced-motion support. Visitors with motion sensitivity should get a fade or nothing at all, never the full effect by default.
This is exactly the bar we built Page Transition Manager against, so I'll use it for the walkthrough below.
Step-by-step: add smooth page transitions with Page Transition Manager
Setting it up takes about two minutes. Head to the Page Transition Manager listing in our Code components library and copy it into your project.
Place one instance on any page of your Framer project, ideally inside a shared/global component so it applies site-wide with a single edit. It has no visible size on the live site, so exact placement on the canvas doesn't matter.
Pick a transition from the properties panel, 15 presets are built in, from a simple Fade to Circle Reveal, Directional Wipe, or a fully Custom curve.
Tune the timing, one overall duration or split Exit/Entry, and choose an easing curve.
Then press Preview and click between your pages. Since it's built to behave identically in Preview and live, what you see while designing is exactly what visitors will get.
Choosing the right transition for your site
Not every transition suits every kind of site, so it helps to start from what the site is actually for.
Agency and portfolio sites tend to want something quiet: a Fade or Curtain reads as premium without calling attention to itself.
E-commerce and product sites benefit from a Directional Wipe between category and product pages, it gives a sense of forward motion through the catalog rather than a jump-cut.
Case studies and project reveals are the one place I'd actually turn the volume up, Circle Reveal or Scale makes the transition part of the storytelling instead of just a housekeeping detail.
If you're not sure which of those describes your site, start with Fade at a short duration, somewhere around 0.4 to 0.6 seconds. It's the safest default, and it rarely feels out of place.
Common mistakes to avoid
A few things trip people up even after the setup itself is done right.
The most common one is only adding the component to some pages. If a page is missing the instance, links into it navigate with no exit animation at all, which reads as a bug rather than a deliberate choice. The fix is simple, just easy to forget once the excitement of seeing it work wears off.
The second is skipping the Preview test and only eyeballing the canvas. Always click through your actual page links in Preview before you publish.
The third is leaving Reduced Motion on its default instead of picking a mode that respects visitors' system preferences. And the fourth is greed with duration, anything past about 0.8 seconds stops feeling polished and starts feeling like the site is slow.
Final thought
Page transitions are one of those details visitors never consciously notice when they're done right, and immediately notice when they're done wrong. Building a reliable one from scratch means solving for Preview parity, external links, rapid clicks, and failure recovery, none of which are visible until something breaks in front of a real visitor.
If you'd rather skip that process, Page Transition Manager ships with all of it solved. Drop it in, pick a preset, and you're done.
Questions about setup? Contact us, and we'll help you get it running.
Got an article suggestion? Let us know