Interactions with GSAP

GSAP is a JavaScript animation library created by GreenSock. It does one job very well: it changes a numeric property of something (a CSS property, an SVG attribute, a variable) from one value to another over time, with an easing curve, and it lets many such changes be arranged on a timeline. Browsers have two native tools for this, CSS transitions and CSS animations, and a third, the Web Animations API. GSAP predates the last one, works around many cross-browser differences, and adds the things that are hard to do natively: sequencing many animations with exact relative timing, staggering a group of elements, scrubbing an animation to the scroll position, splitting text into words and letters, and animating along an SVG path.

The library has a core and a set of plugins. The ones that matter for Webflow users are named in the panel itself or are visible in its results:

Webflow has had visual interactions since 2012. That first engine, widely called IX2, is now labelled Classic Interactions, and Webflow launched a replacement, Interactions with GSAP, in 2025. The announcement said it would roll out to everyone by the end of July 2025, at no extra cost and on every plan. The older version was not removed: the Interactions panel has a version dropdown at the bottom, and a site that already contains Classic interactions keeps working. A new site, and any site without Classic interactions, defaults to GSAP. If an article describes an option you cannot see, the first thing to check is that dropdown.

The two systems do not share a data model, and an interaction is not converted from one to the other. The official comparison lists, among other differences:

Webflow’s recommendation is to use GSAP for most new work and to keep Classic where a site depends on something only Classic offers. The Classic Interactions page describes the older system, what still requires it, and how to switch, and Scroll and Page Animations builds the scroll recipes on this page’s foundations. Because both runtimes exist, a site that mixes them ships the code for both, which is one reason to finish a migration rather than leave a site half converted.

Source: Webflow Help Center: Interactions with GSAP vs. Classic Interactions

Source: Webflow updates: Introducing Webflow Interactions, powered by GSAP

An interaction in the GSAP system is described with four words. Each of them is a different question, and mixing them up is the commonest source of confusion for beginners.

The trigger target and the action target are independent. A click on a button (trigger target) can open a panel somewhere else on the page (action target), and one action can have several targets at once. This is the essential improvement over the Classic model, where the element that starts an animation and the elements it changes were tied together more tightly. In the Interactions panel, the target of a trigger and the target of an action are chosen separately, using the element on the canvas, a class, or a relationship to the trigger element such as its children, siblings or parent. The December 2025 update improved exactly this relative targeting.

The word animation is used for an action that changes a value over time, for example "fade in" or "move up". A preset is an animation with settings already filled in. An instantaneous action, called Set, is not an animation, but it sits on the same timeline.

Source: Webflow Help Center: Triggers, targets, actions, and animations overview

Source: Webflow Help Center: Glossary for Interactions with GSAP

The timeline is what distinguishes Interactions with GSAP in the Designer. It is a horizontal ruler of seconds, and every action appears on it as a block. Blocks are grouped into tracks, which organise them by element or by purpose, so that all the blocks that change the hero heading sit together. A block has a start position, a duration, an easing curve and the property or properties it changes. Dragging a block moves its start; dragging an edge changes its duration.

The model comes straight from GSAP: a GSAP timeline is a container that holds tweens and places each of them at a position in time. Webflow’s glossary states that the positions in its timeline are all absolute, meaning a block’s start is stored as a number of seconds from the start of the timeline, and not only as "after the previous block". The GSAP documentation describes the three ways a position can be written in code: an absolute time in seconds, a label, or a relative pointer such as the start or end of the previous animation. The panel shows the result of such decisions as block positions. A person who is used to code can read a block’s start time as the second argument of a GSAP tl.to() call.

Source: Webflow Help Center: Interactions timeline

Source: GSAP documentation: Timeline addLabel()

Triggers are chosen in the Interactions panel after selecting an element and choosing New interaction. The panel offers the following, and each one has its own settings.

An action is one step on the timeline. Some actions are instantaneous; others interpolate values over time. The panel groups them as follows.

Every interpolated action has a duration, an easing curve and a start position. The easing editor lets you pick a named curve or draw one, and the choice often matters more than the duration: an ease-out (fast start, slow end) feels natural for things that arrive, and an ease-in for things that leave.

A preset is an action saved with its settings so that it can be applied again. To make one, build an action, then use the Save as preset bookmark icon next to the action’s name. The saved preset is listed in the Interactions manager, the panel on the left side of the Designer where all the interactions and presets of a site are listed and searched. Webflow provides a set of starter presets as well. The advantage of presets is consistency: every fade-up on the site is the same fade-up, with the same duration and easing, and changing the preset’s definition is a single decision.

The launch of Interactions with GSAP also made reuse a central idea: an interaction can be defined once and applied to several elements or classes, instead of being rebuilt for each. A design system keeps a short list of motion presets, named by intent (Reveal up, Soft hover, Card ripple), and the people who build pages choose from the list. This is the motion counterpart of the colour and spacing variables described in Building a Design System.

Two other controls help manage a crowded panel. An action can be hidden: a hidden action stays on the timeline and remains editable, but does not run, which is the right tool for testing a page without one of its effects. And an interaction has a name, which should say what it does and where, such as "Home hero entrance", because a site with sixty interactions called "Interaction 12" is unmaintainable.

Source: Webflow Help Center: Create and manage Interactions with GSAP

An entrance animation usually starts from a state that is not the page’s normal state: the heading is transparent and 40 pixels low, and it moves to its normal place. The browser paints the page before the animation script starts, so for a moment the heading is visible in its final position, then disappears, then animates in. That flicker is a flash of unstyled content, abbreviated FOUC, here a flash of the initial state.

Webflow now prevents it automatically for Interactions with GSAP. Its help article says the platform hides elements that begin in a "from" or "from and to" state, and reveals them when the animation is ready to initialise. The mechanism is visible in the page: a small script injects a CSS rule that sets visibility: hidden !important on the affected elements, and when Webflow is ready to start the animation it adds the class w-mod-ix3 to the document’s root element, which releases them. Before this feature existed, forum posts recommended setting the element’s initial opacity in the style panel to match the animation, which a designer then had to undo.

The same article names the failure case. When one element has several animations that start from different states, the automatic hiding cannot know which to apply. The remedy is to change the animations to "to" tweens, which start from the element’s normal style, or to separate the animations onto different elements, typically a wrapper and its child. Two more habits help: do not animate an element’s display, which is not interpolable, and check the page with the network throttled, because the flash is most visible when scripts are slow.

A side effect to know about: if the script never loads, the elements stay hidden. Webflow’s runtime is part of every published page, so this is rare, but a site that blocks scripts through a consent tool or a corporate filter can show a page with missing content. Do not hide content that matters, such as a price or a legal notice, behind an entrance animation.

Source: Webflow Help Center: FOUC prevention for Interactions with GSAP

Interactions with GSAP supports real-time collaboration, which the official comparison lists as a feature that Classic Interactions lacks. Two designers can work in the same project at once, and a designer can build an interaction while a colleague styles the elements it targets. Two habits keep this safe: agree who owns an interaction, because two people editing the same timeline at the same time produce a result that neither of them intended, and name interactions clearly, so that a colleague finding "Home hero entrance" knows what it touches. Review is easier on a branch: Page Branching, Releases and Approvals shows how a page with new motion is reviewed before it is merged. Comments and the activity log are covered in Collaboration, Comments and the Activity Log.

Interactions are part of the project, so they are covered by the backups described in Backups and Recovery. Whether interactions are included in a code export is covered on Code Export and Portability; check the exported folder rather than assume, because an animation that depends on Webflow’s runtime does not necessarily run outside it.

Chapter 7 of Webflow by Example teaches interactions with a three-part habit. This page restates it in its own words and adapts it to the GSAP model, because the habit survives the change of engine and a designer who has it produces fewer tangled timelines.

Step 1: decide the initial state. Before touching the panel, say what the element looks like before the animation starts. "Invisible, 40 pixels lower, and slightly smaller" is a complete description. If the initial state is the element’s normal style, the element needs no initial state and the animation is a "from" tween that ends where the design ends.

Step 2: decide the final state. The final state is almost always the normal design: opaque, in place, full size. The reason to keep the final state equal to the normal style is that the page remains correct when the animation does not run, because of reduced motion, a disabled breakpoint, a script failure or a screenshot tool. A design whose final state differs from its normal style is a design that breaks when the interaction is switched off.

Step 3: decide the transition. The transition is the path between the two: duration, easing and position on the timeline. Keep durations between roughly 0.2 and 0.8 seconds for interface motion, use an ease-out for entrances and an ease-in for exits, and stagger by 0.05 to 0.2 seconds. Longer transitions belong to deliberate storytelling, such as a scroll scene.

Step 4 (the addition for GSAP): decide the order. With the timeline, an animation has a fourth question: which block is first, which overlap, and which wait? Write it as a list before building. The Fernbrook event card is "panel fades in (0 to 0.6 s); heading moves up (starts at 0.4 s); the three price cards stagger in (starts at 0.8 s)".

The book works with Webflow’s Classic Interactions, where the steps are labelled differently, and the book’s screens do not match the Interactions panel in 2026. Its method, not its screenshots, is what carries over.

Fernbrook Gardens wants its events page to open with a short entrance, a clear call to action and respect for visitors who prefer less motion. The design, applying the method:

The same structure, written out for the interactions of a real site, is a table that goes into the design-system documentation: interaction name, trigger, target, actions, durations, breakpoints, reduced-motion behaviour and owner.

A visual interaction is stored in the Webflow project, not in your code, and the published page carries a compiled version of it. Understanding what ships helps with performance, debugging and portability. Inspect the published page with the browser’s developer tools to see the exact markup, because Webflow’s internal attribute names and script file names are implementation details that can change between releases.

A developer who wants to coordinate with these interactions has two supported routes. The first is the custom event trigger shown earlier. The second is to load GSAP from Webflow’s CDN and drive other elements from custom code, taking care that code and panel do not animate the same property of the same element. A minimal example that animates a Fernbrook ticket counter, and respects reduced motion, is below. It is written as a script for Page settings > Custom code > Before </body> tag of the ticket page, after enabling the GSAP integration in site settings.

The script waits for Webflow to be ready, uses gsap.matchMedia() to detect the reduced-motion preference, and sets the duration to zero for visitors who prefer less motion, so that they see the final figure immediately. The counter is an attribute selector, which keeps the script independent of class names.

Source: Webflow Help Center: Getting started with GSAP in Webflow

Interactions are code that runs on every visit, so their cost is part of the page’s cost. The rules are the ones that apply to animation anywhere.

Not every movement needs the Interactions panel. A useful order of preference is to use the simplest tool that does the job, because each step up adds weight and maintenance.

The CSS-first rule is also an accessibility and resilience rule. A hover state in CSS never leaves the page hidden if a script fails, and it does not need a reduced-motion switch for a change of colour.

A site with a handful of interactions can be managed by memory. A site with dozens needs the same discipline as its colours and spacing. The Fernbrook design system has a short motion section.

Four rules keep the system coherent. Durations and easings come from the table, not from taste on the day. Each preset has a reduced-motion twin, so the switch for visitors who prefer less motion is a rule instead of a hundred decisions. Each interaction is named after its purpose and page. And every new preset is added to the table first, so that the next person finds it.

Reduced motion is the setting Webflow provides, and it is only part of the obligations. Success criterion 2.2.2 of WCAG 2.2 requires that content that moves for more than five seconds and starts automatically can be paused, stopped or hidden, which applies to an endless looping background or a carousel. Criterion 2.3.1 forbids content that flashes more than three times a second. A scroll-pinned section must not trap a keyboard user. Content must be reachable without the interaction: if a paragraph appears only on hover, a keyboard visitor and a touch visitor never see it. The Accessibility page gathers these checks for the whole site.

Interactions built in the panel contain no code of yours, so they add no script-injection surface. The risks come from the code around them. A custom event trigger accepts any script that can dispatch an event with the right name, so a third-party script on the page can start an interaction; that is acceptable for an animation and unacceptable if the interaction changes anything sensitive, such as revealing a hidden form. Custom GSAP code and third-party tags run with full access to the page, so they follow the rules of Third-party Libraries and Scripts: load from a source you trust, pin versions, and review who can edit the custom-code fields. In an Enterprise workspace the roles and permissions described in Plans, Workspaces, Seats and Roles decide who can publish changes, including motion.

The following dates come from the Webflow updates feed and are useful when an older article seems to contradict the panel.

Books and tutorials from before 2025 describe Classic Interactions, and a reader who follows them in the current Designer will not find the same screens. The points that matter most:

The complete list is on Where Older Books and Tutorials Are Outdated, and the product timeline is on Product Changes and Deprecations.