GSAP easeReverse: The One-Line Fix Every Modal Needs

Estimated reading time: 6 minutes | Skill level: Intermediate

When a modal opens with a bounce, then closes by reversing the same animation, something feels off. The exit drags. The bounce is gone. Most developers paper over this by writing two separate animations. One for open, one for close. Different easing on each. It works. It's also twice the code.

GSAP 3.15 fixed this with one property: .

The actual problem

When you call on a tween or timeline, GSAP plays time backwards. That sounds obvious, but it has a specific consequence for easing. An curve looks like this when played forward: fast start, slow finish. Played backwards, it becomes: slow start, fast finish. That's an . Same data, opposite feel.

For motion that should ease out in both directions (like a menu that pops open AND pops back), reversing time is the wrong tool. The exit feels weak. People notice without being able to name what's off.

How easeReverse works

You pass alongside in your tween vars. reuses the same forward ease when the playhead moves backwards. The reverse now feels like the forward play.

You can also pass a different ease string:

This is the pattern I reach for on menus and drawers. Bounce in, ease out softly. The two directions don't have to match.

Where this actually matters

Three patterns where the asymmetry shows up most:

Toggleable overlays. Modals, drawers, menus, tooltips. You want a punchy entrance and a clean exit.

Notice the block. Every tween in the timeline picks up going forward and coming back. No per-tween repetition. This was the pattern I wanted for years. Hover states with overshoot. A ease on hover-in feels right. Played in reverse, it overshoots in the wrong direction. keeps the entrance bouncy and the exit clean.

Interrupted animations. If a user toggles a menu before the previous animation finishes, GSAP recalculates the curve from the exact frame the playhead changed direction. No glitch. No reset.

Timeline defaults

The pattern that scales: set once in the timeline defaults, override per tween only when needed. The tween uses its own . The other two use the timeline default. This is the reason lives at the tween level instead of being a timeline-only setting.

yoyoEase is dead

Before 3.15, the closest thing was . It only worked when you also set on a repeating tween. It was a niche feature for ping-pong loops, not for the pattern most apps actually need. GSAP 3.15 deprecates . Existing code keeps working. New code should use .

When not to use it

If your animation only ever plays forward, you don't need this. Skip it. is for animations you actually call on, or for tweens where the playhead changes direction at runtime. For ScrollTrigger scrubbed animations, doesn't apply the same way. ScrollTrigger scrubs through timeline progress, so the easing follows the scroll position, not a discrete play/reverse call.

Key takeaways

• reverse()
  plays time backwards, which inverts your ease curve. That's the real reason reversed animations feel off.
• easeReverse: true
  reuses your forward ease.
  easeReverse: "ease.name"
  lets you pick a different one.
• Set it in
  timeline.defaults
  so every child tween inherits it.
• Deprecates
  yoyoEase
  . Use
  easeReverse
  instead.
• Most useful for toggleable UI: modals, menus, drawers, hover states with overshoot.

Build it without the boilerplate

Most of the menu, button, and overlay animations in the Annnimate library already use the open-then-reverse pattern. With GSAP 3.15 and , the exit feel matches the entrance without doubling the code. Drop them into your project and tune the curves to taste.

For a deeper look at the play/reverse pattern, the GSAP Timeline Tutorial covers timeline defaults and playback control in detail. And the GSAP Hover Effects guide shows where this asymmetry hits hardest.