Touch Gestures Snippets — Free HTML CSS JS Swipe & Touch Gesture Examples

Touch interfaces are built from a small vocabulary — swipe, drag, pinch, long press, double tap — and each one has a threshold and a feel that has to be tuned rather than guessed. These snippets implement that vocabulary with pointer events, so the same code path serves mouse, touch and stylus.

They follow the platform conventions people already expect: a card that follows the finger and snaps past a distance threshold, a sheet that can be flung closed, a long press that gives feedback before it fires, and gestures that stop fighting the browser's own scrolling.

One event model for every input type

Pointer events unify mouse, touch and stylus behind a single API, carrying pressure and tilt data when the hardware provides it and supporting pointer capture — the mechanism that keeps a drag tracking correctly even after the finger moves outside the original element's bounds. Building on pointer events instead of the older, touch-specific TouchEvent API is what lets every snippet here behave identically whether it is tested with a mouse on a laptop or a thumb on a phone.

Distance and velocity together

A swipe-to-dismiss or swipe-to-action gesture commits based on two signals, not one: how far the pointer travelled, and how fast it was moving at release. Distance alone makes a fast, short flick feel unresponsive since it falls short of the threshold; velocity alone makes a slow, deliberate drag fail to register. Combining them — commit past a fraction of the element's width, or on a fast release even short of that — is what makes the gesture feel right under both a hurried flick and a careful drag.

Resistance and release, not just movement

Pull-to-refresh, sheet-drag and similar gestures use a resistance curve rather than a raw 1:1 pixel mapping, so the further something is dragged past its natural range the harder it becomes to pull further. Combined with a spring-back animation when the pointer releases below the trigger threshold, this is what makes a gesture feel physical instead of just tracking a coordinate.

Not fighting the browser's own scrolling

A custom gesture and native scrolling compete for the same pointer input unless told otherwise. Setting touch-action explicitly — none for a fully custom gesture, pan-y when only horizontal movement should be intercepted — tells the browser up front which axis to leave alone, which is more reliable than calling preventDefault inside a touch handler, since that call does nothing in a passive listener.