Canvas Pixelate Image Reveal — Free Scroll/Hover Sharpen Effect

The pixelate reveal is the "developing photograph" effect: a card starts as a chunky, low-resolution mosaic and sharpens smoothly into full detail as it scrolls into view or is hovered. The whole trick lives in two canvas properties — drawing at a tiny resolution, then reading that tiny canvas back at full size with imageSmoothingEnabled = false.

Why downscale-then-upscale produces pixel blocks

drawAtResolution(cells) first draws the full-detail source image onto a tiny offscreen canvas only cells pixels wide — at cells = 6, an entire 320px-wide card is represented by six columns of pixels. That tiny canvas is then drawn back onto the visible canvas at full size. With ctx.imageSmoothingEnabled = false on the destination context, the browser's own scaling algorithm switches from bilinear interpolation to nearest-neighbor, so each of those six source pixels becomes one crisp, hard-edged block rather than a blurry smear. Toggling that single boolean is the entire difference between a "pixelated" look and a "blurry" one.

A source that's never redrawn small

The full-detail image is painted once, at native resolution, onto its own offscreen src canvas via paintSource() (a gradient plus a few soft circular blooms, since there's no external image to load). Every reveal frame downsamples fresh from that same source — it's never progressively degraded by repeatedly scaling an already-scaled canvas, which is what keeps the "full detail" end state actually sharp instead of soft after a few reveal cycles.

Easing resolution instead of jumping to it

Rather than snapping straight from 6 cells to 96, animate() eases current toward a target cell count with current += (target - current) * 0.12 every frame — the same simple spring-like approach used for numeric tweens throughout this library. Because cells is rounded before each redraw, the visible result is a smooth, discrete step-up in resolution rather than a single hard cut, which reads as "sharpening" instead of "swapping images."

Two triggers, one animation function

Both card.addEventListener('mouseenter', reveal) and an IntersectionObserver calling the same reveal() on first scroll-into-view drive the identical animation path — there's no duplicated logic for "reveal by hover" versus "reveal by scroll." The observer uses a WeakSet to reveal each card only once on its first appearance, while hover continues to work afterward via mouseleave re-pixelating and mouseenter re-sharpening.

Extending it

Swap paintSource for a real ctx.drawImage(yourImg, 0, 0, W, H) once an image has loaded; tie target's cell count to scroll progress instead of a boolean for a scrubbable reveal; or pair the technique with image blur-up for a hybrid loading placeholder, or scroll reveal grid for the surrounding entrance choreography.