Not the way it used to be. Webflow now owns GSAP, and its current interactions engine is built on GSAP. So the real question in 2026 is not which library to pick. It is whether to build your motion visually in the Interactions panel or write GSAP by hand in custom code.
That is a much better question, because the answer changes per project rather than per studio. Both paths run the same animation engine underneath.
Here is how the pieces fit together, what actually changed, and how we decide which route a build takes.
Webflow acquired GreenSock Animation Platform in the fall of 2024, and then made it free. In a post by Chief Product Officer Rachel Wolan, Webflow said GSAP is now 100 percent free for everyone, whether or not you are a Webflow customer, including the plugins that used to sit behind the paid Club membership. Webflow also expanded the standard licence to cover commercial use.
That second part is the one that mattered most to agencies. For years, using plugins like SplitText or ScrollSmoother on a client project meant buying a membership and tracking the licence. That cost is gone.
Webflow also rebuilt SplitText, one of the most used plugins in the library. The company said the rewrite brought a 50 percent file size reduction, accessibility for screen readers built in, easier masking for reveal effects, and 14 new features in total.
The strategic read is simple. Webflow bought the animation engine that the best sites on the web were already using, then removed the price so more people would use it, then rebuilt its own product on top of it.
Interactions with GSAP is Webflow's rebuilt motion engine. Webflow launched it on 10 July 2025, describing it as the ability to build sophisticated GSAP-powered animation without writing a line of code, including GSAP features like SplitText, staggers, and ScrollTrigger. It ships with a horizontal timeline and reusable interactions.
Classic Interactions is the older engine. At launch, Webflow said Classic would stay the default and that you could switch between the two versions freely from the Versions dropdown at the bottom of the Interactions panel.
That has since changed. Webflow's help documentation now describes Interactions with GSAP as the recommended version and the default on new sites. So a site you start today begins on the new engine unless you deliberately go back.
The workflow differences are real. The new engine uses a trigger, target, and action model, and Webflow's documentation describes scoping interactions to components and variants so motion travels with a component when it is reused across pages, across sites, and through Shared Libraries.
No. If you are starting fresh, start on the version Webflow is building. Classic Interactions still works and Webflow lets you switch between versions, but every new capability we have watched land has landed on the GSAP engine, not on the old one.
The exception is an existing site with a lot of complex Classic animation. Rebuilding all of that mid-project because a newer engine exists is not a good use of anyone's budget.
Our rule on client work is that new builds go on Interactions with GSAP, and existing Classic sites move when they are being rebuilt anyway. Motion is not the reason to start a rebuild, but it is a nice thing to inherit when one happens.
Most of the time, on most business sites. If your motion is scroll reveals, staggered lists, hover states, hero text splits, and section transitions, the visual editor does all of that now, and it does it in a place a designer can adjust without a developer.
The reason we favour it is maintenance rather than speed of build. Custom code animation lives in a script that only the person who wrote it fully understands. An interaction built in the panel is visible to anyone with Designer access.
Reuse pushes the same way. When motion is attached to a component and that component travels through Shared Libraries, the animation stays consistent across every page it appears on. Hand-written code tends to drift, because each new page gets its own slightly different copy.
If you want the fuller picture of building motion inside Webflow, our guide to building smooth animations in Webflow goes through the mechanics in more detail.
When the animation is genuinely a program rather than a sequence. Physics, custom easing driven by input, canvas and WebGL work, motion tied to live data, and anything where one animation needs to react to the state of another are all cases where code is the honest answer.
The second case is coordination across many elements with conditional logic. A timeline editor is excellent at describing what happens. It is less suited to describing what happens only when three other things are true.
The third case is portability. Webflow's DevLink component export now ships interactions built with the GSAP-powered engine, including triggers, timelines, and plugins, into a React project. That closes much of the old gap, but if the animation needs to live somewhere Webflow does not reach, writing it yourself keeps it yours.
We do not treat custom code as the advanced option and the panel as the beginner one. That framing is vanity. The panel is the right default, and code is the escape hatch for the ten percent it cannot express.
Through Site Settings, not through a script tag you paste in yourself. Webflow said all GSAP plugins are now directly available in and hosted by Webflow. You toggle on the GSAP Core library and the plugins you want, then write your animations in custom code.
This replaced a genuinely annoying process. Before, using a Club plugin meant handling a private download and hosting the file somewhere yourself, which broke every time the licence or the URL changed.
Webflow also added the ability to preview a site with custom HTML, CSS, and JavaScript applied before publishing, which includes GSAP animations. That means you can see whether your code works without pushing it to a live client site first.
If you are adding code to a Webflow project, do it with a plan for where it lives and who maintains it. Our notes on using custom code in Webflow without breaking your site cover the habits that keep this from becoming technical debt.
It costs JavaScript, so it is never free, but the cost is manageable if you are deliberate. Every plugin you toggle on is more code the browser downloads and runs, and animation work happens on the main thread, which is exactly where responsiveness problems come from.
The mistake we see is enabling every plugin because they are now free. Free to licence is not free to load. Turn on the ones a page actually uses.
The SplitText rewrite helps here, since Webflow put a 50 percent file size reduction at the top of the improvement list. Smaller plugin, same effect.
Watch Interaction to Next Paint rather than just the load metrics. Heavy scroll-linked animation is a classic cause of a page that scores well on paint speed and still feels sticky under a finger. We look at whether motion earns its cost in our piece on whether website animations help or hurt conversions.
This is the part both routes get wrong equally often. Some people have motion sensitivity, and operating systems let them ask for less of it. Browsers expose that as the prefers-reduced-motion media feature, and your site should respect it whether the animation came from a panel or a script.
Text splitting deserves particular care, because splitting a heading into characters or words can confuse screen readers if it is done carelessly. Webflow specifically called out screen reader accessibility as part of the SplitText rewrite, which suggests they knew that was a real complaint.
Our practical test is to turn reduced motion on in the operating system and use the site. If content becomes unreachable, or a scroll-triggered element never appears, the animation is not a decoration any more. It is a blocker.
Build in the panel by default, drop to code when the panel cannot express what you need, and stop treating the two as rival camps. They run the same engine. Interactions with GSAP is the recommended version on new Webflow sites, custom GSAP is a toggle away in Site Settings, and neither costs you a licence any more.
If you are picking a path today, the question worth asking is not which is more powerful. It is who has to maintain this in a year. On most client sites, that person is a marketer, and the answer follows from there.
The wider shift is that good motion is no longer gated behind a budget line. It is gated behind restraint. Now that every plugin is free, the discipline is choosing not to use most of them.
If you want help deciding how much motion a project actually needs, or you have a Classic Interactions site you are wondering what to do with, we are happy to walk through it. Let's talk at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.