How Webflow Interactions Work

Webflow's current animation system is Interactions with GSAP, built on the open-source GSAP engine, and it works as a trigger/target/action model — a trigger like click, hover, or scroll starts one or more actions on chosen target elements, sequenced on a visual timeline. Webflow also still runs an older system, Classic Interactions, side by side with it for sites that already used it. Here's how each one actually works, sourced from Webflow's help center, checked September 2026.

What's the difference between Interactions with GSAP and Classic Interactions?

Webflow's own comparison article is direct about the split: "Interactions with GSAP launched in summer of 2025. It is the most robust and up-to-date version of interactions, and uses the GSAP engine for creating, editing, and displaying interactions... This version of interactions employs a trigger/target/action creation model" (Webflow Help Center, "Interactions with GSAP vs. Classic Interactions", checked September 2026). Classic Interactions, by contrast, "employs a Page/element triggers > animations creation model" and existed before the GSAP-powered version. Both are available today — Webflow lets you switch between them using a dropdown at the bottom of the Interactions panel — but "Interactions with GSAP is the recommended version... and the default on all new sites."

A few concrete things are still only on one side or the other, per Webflow's own comparison table: Classic Interactions is currently the only version with navbar/dropdown/tab/slider change triggers, page branching support, and interactions included in component exports (DevLink). Interactions with GSAP is the only version with the horizontal timeline, real-time collaboration, repeat/stagger/split-text actions, a reduced-motion setting, and component-instance-scoped interactions. Webflow says it's "actively closing that gap" between the two.

How do triggers and targets work in Interactions with GSAP?

An interaction has four parts: "Trigger type — click, hover, page load, etc. Trigger target — the element (or elements) the trigger acts upon. Action — a reaction to a trigger. Action target — the element (or elements) that are affected by the action" (Webflow Help Center, "Intro to Interactions with GSAP", checked September 2026). The available trigger types are Click, Hover, Mouse move, Page load, Scroll, and Custom event (Webflow Help Center, "Triggers & targets in Interactions with GSAP", checked September 2026). Most triggers, like Click and Hover, "fire once when an event happens." Mouse move is different — it's "a continuous trigger that tracks the cursor's position and drives your interaction's timeline for as long as the cursor is inside the trigger's tracking area."

One real limitation to know before rebuilding an older interaction: "GSAP-powered interactions don't support Webflow element-specific triggers (i.e., navbar, tabs, dropdown, and slider)." If your site relies on a navbar-open or tab-change animation, that specific trigger type currently still requires Classic Interactions.

Targeting works by element ID, class, attribute, or "the element that initiated the interaction," and you can scope a target further — to children, siblings, the parent, or a matching descendant/ancestor with a specified selector — so a single interaction on a repeated component (like a card grid) can affect only the elements related to the one instance a visitor interacted with, not every matching element on the page.

How does scroll-based animation work?

Scroll is one of the six trigger types listed above, alongside Click, Hover, Mouse move, Page load, and Custom event. Webflow's own product page describes the practical result in plain terms: interactions let you build things like "parallax scrolling sections" among other scroll- and interaction-driven effects (Webflow, "Build web animations visually with Webflow Interactions", checked September 2026), and the Intro to Interactions with GSAP article covers uses from simple scroll-triggered reveals to multi-step sequences. Webflow's built-in GSAP features "like SplitText, Staggers, and ScrollTrigger" are available directly inside the same panel rather than requiring a separate code embed.

In Classic Interactions, the equivalent scroll behavior is split across the Element triggers ("Scroll into view," "While scrolling in view (continuous)") and Page triggers ("Page scrolled," "While page is scrolling (continuous)") sections, each with its own configurable scroll offset that "delays the interaction from starting until it reaches a certain scroll percentage of the page" (Webflow Help Center, "Triggers and animations in Classic Interactions", checked September 2026).

Does Webflow's Interactions system use GSAP directly?

Yes, as the name states. Webflow's own release framing puts it plainly: Interactions with GSAP "uses the GSAP engine for creating, editing, and displaying interactions," and gives visual-canvas access to "built-in GSAP features like SplitText, Staggers, and ScrollTrigger" without writing GSAP code by hand. That's a meaningfully different claim from "compatible with GSAP" — Webflow is describing GSAP as the actual rendering engine behind the panel, not an optional add-on.

What happens to interactions inside a component or design system?

Interactions with GSAP is built to travel with reusable components: you can scope an interaction to "the component and runs on all instances, wherever they're used" (a "Main component" scope) or to a specific variant, and Webflow states that "component-scoped interactions are included in Shared Libraries and travel with the component when it's installed on other sites." A page-scoped interaction added to one component instance, by contrast, "doesn't travel with the component" — worth knowing if you expect an animation to follow a component everywhere it's reused and it doesn't, because it was accidentally set at the instance level instead of the component level.

What performance notes does Webflow give?

Two, directly stated. First, running both systems on the same site has a real cost: Webflow ranks expected performance from best to worst as "Interactions with GSAP only," then "Classic interactions only," then "Interactions with GSAP + Classic interactions" — because "each version of Webflow interactions requires load in of its own resources, so the more versions of interactions you use on a site, the less performant your site will be." Second, Webflow states that Interactions with GSAP is "the only version that will be forwards compatible with new features."

Webflow also documents a specific troubleshooting case: "Interactions may not work as expected on published sites if your site incorporates custom code," and Webflow's support team won't debug that interaction between custom code and its own interaction engine directly — that's a Webflow Forum question, not a support-ticket one.

What accessibility settings does Webflow document?

Webflow's help center names the real risk directly: "Certain web animations and flashing content can negatively affect the health and well-being of people with vestibular and photosensitivity disorders. This can include triggering motion sickness and seizures." Its stated best practices are to make sure base animations meet WCAG guidance without requiring a visitor to change a device setting, and separately, to respect a visitor's OS-level motion preference through conditional playback — setting an interaction to "no animation" or "skip to end" for people with reduced-motion enabled, rather than playing the full animation regardless.

Webflow also documents automatic Flash of Unstyled Content (FOUC) prevention for from/to-based animations: "Webflow automatically prevents FOUC when you use Interactions with GSAP, so your animations play smoothly from the start" — a browser-rendering glitch Webflow says it handles for you rather than something you need to work around manually.

What's the recovery path if an interaction breaks a layout?

Because an interaction is a setting attached to an element or component rather than injected code, removing it is non-destructive: reopen the Interactions panel for the affected element, find the interaction, and delete or disable it. If you're troubleshooting whether an interaction (versus something else on the page) is the cause of a layout problem, Webflow's own guidance points first at custom code as a common conflict source — temporarily disabling any custom code on the page is a reasonable first check before assuming the interaction itself is broken.

Where does Figment fit in, and how does this compare to Framer?

Figment publishes a static site from a Figma design through its Figma plugin; it doesn't have a trigger/target/action interaction builder, a GSAP-powered timeline, or component-scoped animation to compare against what's described here. If motion is the actual deciding factor between website tools, our guide to how animations work in Framer covers Framer's separate system — built on its own Motion library rather than GSAP — including its Appear effects, Scroll Transforms, and Code Overrides, so you can compare the two systems on the same terms. For a broader side-by-side on ownership, hosting, and CMS beyond animation specifically, see our Framer vs. Webflow comparison.

Bottom line: Webflow's current, default animation system is Interactions with GSAP — a trigger/target/action model covering Click, Hover, Mouse move, Page load, Scroll, and Custom event triggers, built on the GSAP engine, with component-scoped reuse and automatic FOUC prevention. Classic Interactions still exists for sites that need its remaining element-specific triggers, but running both on one site costs real performance, and Webflow recommends the GSAP version for anything new.