Text Particles HTML CSS JS — Canvas Particle Text

A particle text effect renders a word as thousands of tiny dots that fly in, assemble into the letters, hold the shape, and can scatter apart on click before reforming. It is one of the most eye-catching canvas effects and, despite looking complex, comes down to two ideas: sampling glyph pixels from an offscreen canvas to find target positions, and spring physics to move particles toward those targets. This walkthrough explains the whole pipeline, built with the HTML5 Canvas 2D API and requestAnimationFrame, no libraries.

Sampling text into target points

The particles need to know where the letters are. To find out, the code draws the word onto a hidden offscreen canvas with a large bold font using fillText, then calls getImageData to read back the entire pixel buffer. The returned Uint8ClampedArray holds four bytes per pixel (R, G, B, A). The code scans this buffer on a stride — stepping several pixels at a time in both x and y rather than every pixel — and for each sampled location checks the alpha byte: if data[index + 3] > 128, that pixel is part of a letter and becomes a particle target. The stride controls density: a smaller stride yields more particles and crisper text at higher cost, a larger stride is sparser and faster. Roughly three thousand particles at a stride of a few pixels gives a clean word while staying smooth.

Each detected text pixel produces a target position (tx, ty). Existing particles are reused and assigned new targets when the word changes, and extra particles are spawned or trimmed so the count matches the new glyph's pixel count.

The particle and spring physics

Every particle stores a current position (x, y), a velocity (vx, vy) and its target (tx, ty). The motion toward the target is a damped spring, the classic ease-with-overshoot integrator:

vx += (tx - x) * SPRING vy += (ty - y) * SPRING vx *= DAMPING vy *= DAMPING x += vx y += vy

The spring term accelerates the particle in proportion to how far it is from its target, like a rubber band — far particles rush in fast, close particles slow down. The damping factor (slightly less than 1) bleeds off velocity each frame so particles settle instead of oscillating forever. Tuning SPRING and DAMPING changes the feel from snappy to floaty. Because every particle runs this independently, the cloud organically converges into readable text.

The state machine: FORM and EXPLODE

The effect is driven by a small state machine. In the FORM state, particles spring toward their text targets and the word assembles. On click (or a timed trigger), it switches to EXPLODE: each particle is given a random outward velocity — a random angle and speed pushing it away from its position — and gravity is added each frame (vy += GRAVITY) so the particles burst and arc downward like fireworks. After a short interval the state flips back to FORM, the spring physics re-engages, and the particles fly home to rebuild the word. This explode-and-reform loop is what makes the effect feel alive.

Rendering efficiently

In the animation loop, the canvas is cleared (or faded for a trail), then every particle is drawn. For performance with thousands of particles, each is rendered as a tiny filled square via fillRect(x, y, 2, 2) rather than arc, because rectangles skip the path and circle math that would dominate the frame budget. Color is assigned per particle from its horizontal position — mapping x across the canvas width to a hue in HSL — so the assembled word shows a smooth left-to-right rainbow gradient that follows the particles even as they move. Drawing flat 2px squares keeps roughly three thousand particles comfortably at 60fps.

Changing the word

A text input lets users type a new word. On apply, the offscreen canvas is recleared, the new text is drawn and re-sampled into a fresh set of targets, and the particle array is reconciled to the new target count. Because particles keep their current positions and simply receive new targets, the transition from one word to the next is itself a smooth animated morph rather than a hard cut.

Why this approach scales

The key insight is decoupling the *what* from the *how*: the offscreen canvas and getImageData answer where the text is, producing a list of target points, while the spring-and-damping integrator answers how particles get there. Neither part needs to know about the other. That separation, plus drawing cheap squares and using requestAnimationFrame, lets a few lines of math animate thousands of particles into any text you type, all on the client with no dependencies.