Scroll Tile Assemble — Free GSAP Mosaic Snippet

The scroll tile assemble starts with twelve tiles thrown across the viewport — rotated, shrunken, half-faded — and as you scroll, each piece flies home into a 4×3 grid that fuses into one continuous panel, with a headline settling on top. Scroll up and the panel shatters apart again. This snippet builds it with GSAP ScrollTrigger (from a CDN), a seeded scatter, and a background-position slicing trick that makes separate tiles read as a single image.

One gradient, sliced across twelve tiles

Every tile shares the same background-image gradient at background-size: 400% 300% — four columns by three rows of the tile's own size. Each tile then shows its slice via background-position: (c/(COLS−1))% (r/(ROWS−1))%, the CSS percentage-positioning formula that maps a grid cell to its window onto the oversized background. When the tiles land, edges align perfectly and the grid reads as one unbroken picture. Swap the gradient for a url() image and you have a photo mosaic with zero markup changes.

The scatter is seeded, not random

Start positions come from sin(seed × 127.1) × 43758.55 % 1 — the classic shader-style hash — fed by each tile's index. It looks random but is fully deterministic: the scatter is identical on every load and every scrub-back, so users who scroll up see the exact shatter they came from. Math.random() would re-scatter on refresh and, worse, if setup ever re-ran, tiles would visibly jump.

GSAP animates from where they are to where they belong

The tiles are laid out by CSS grid in their *final* positions; gsap.set then displaces them with transforms (x, y, rotation, scale). The scrubbed tween simply returns everything to zero — meaning the grid layout is the single source of truth for the assembled state, and the browser handles all responsive sizing. No target coordinates are ever computed in JS.

A random-order stagger sells "pieces arriving"

stagger: { each: 0.06, from: 'random' } offsets each tile's start so pieces stream in from all directions in shuffled order rather than row-by-row — the difference between an assembling mosaic and a sorting animation. Because the offsets live inside one tween, the whole assembly still reads as a single gesture under the scrub.

The copy waits for a surface to land on

The headline fades in at 85% of the timeline, once enough tiles have fused to act as its backdrop. Text-shadows keep it legible over the gradient seams during the final moments of assembly.

Pinned, scrubbed, compositor-only

The stage pins for +=180% with scrub: 0.4; every animated property is a transform or opacity, so twelve simultaneously moving layers stay cheap, and will-change: transform promotes them before the first frame.

Why displacement transforms beat animating grid position

An alternative approach would animate each tile's actual grid-column/row from a scattered layout to the final one, but CSS grid placement isn't tweenable and would require manual absolute positioning with computed pixel targets per tile. Using gsap.set to displace tiles with transforms while CSS grid handles the real, responsive layout means the assembled state needs zero JavaScript-computed coordinates — resize the viewport and the "home" positions recompute for free, while the scatter offsets (in fixed pixels) stay proportionally sensible relative to the grid's own responsive sizing.

Customizing it

Change COLS/ROWS (slicing and scatter adapt automatically), widen the scatter range for a more explosive start, or point the shared background at a product screenshot. Related effects: the inverse scroll grid zoom, staggered entrances in scroll reveal grid, slat-based scroll blinds reveal, and a masonry grid for static layouts.