Bootstrap Animated Counter Stats — Free HTML CSS JS Snippet

A stat that counts up the moment it scrolls into view is a common dashboard and marketing-page effect, and getting it right depends on two browser APIs working together correctly: IntersectionObserver to detect visibility, and requestAnimationFrame to drive a smooth animation rather than a laggy setInterval loop. This snippet lays out four stats in a Bootstrap row with display-5 numbers, each wrapped in a .bsacs-stat div carrying its final value in a data-target attribute (e.g. data-target="10000") so the target number lives in the markup rather than being hardcoded separately in JavaScript.

A single IntersectionObserver is created with a { threshold: 0.4 } option, meaning a stat is only considered "visible" once 40% of it has entered the viewport, avoiding a count-up that fires the instant one pixel peeks into view. When a stat intersects, animateCounter(el) reads its data-target, then drives the animation with requestAnimationFrame: each frame computes elapsed time against a fixed 1800ms duration, converts that into a 0–1 progress value, and runs it through easeOutQuad(t) — t * (2 - t) — so the count starts fast and settles gently into its final value instead of animating at a constant linear rate, which reads as noticeably more polished for this kind of UI.

The critical line for correctness is inside the observer's callback: obs.unobserve(entry.target) is called immediately after triggering the animation. This is the specific requirement that the counters run only once — without it, scrolling the stats row out of view and back again would restart every counter from zero repeatedly, which looks broken rather than intentional on a page where users often scroll up and down past the same section. Each number is written with .toLocaleString() during the animation, so a growing number like 10,000 displays with a comma separator on every intermediate frame, not just at the final value, and font-variant-numeric: tabular-nums is applied via the .bsacs-num class so digits don't visibly shift width frame-to-frame as the number grows from one digit to five, which would otherwise cause a distracting layout jitter during the count.

A separate .bsacs-suffix span (holding "+", "%", or nothing) sits outside the animated number span entirely, so the suffix never gets overwritten by numEl.textContent assignments each animation frame.

The start timestamp inside animateCounter() is deliberately initialized to null and set on the very first frame received rather than being computed from performance.now() up front, because the first value requestAnimationFrame hands its callback is already a high-resolution timestamp anchored to the same clock — capturing it on that first call keeps elapsed accurate to the millisecond the animation actually began rendering, instead of drifting by however long it took the browser to schedule that first frame.