Voice Message Bubble — Free HTML CSS JS Chat Snippet

Every major chat app — WhatsApp, iMessage, Telegram, Signal — renders voice notes the same way: a row of thin bars whose heights look like a real audio waveform, with a moving line or color sweep showing how much has played. Building that convincingly requires answering two separate questions correctly: where do realistic-looking bar heights come from without an actual decoded audio buffer, and how does the "played" portion stay perfectly in sync with a playback clock while still being draggable. This snippet answers both with plain JavaScript, a seeded pseudo-random generator, and requestAnimationFrame, with no audio file and no Web Audio API involved — it simulates the timeline the same way a design mockup or a demo needs to.

Generating the waveform once, not per frame

The tempting-but-wrong approach is to calculate bar heights inside the render loop, which would make the waveform flicker to a new random shape on every animation frame. Instead, generateBarHeights(count, seed) runs exactly once, immediately when the script loads, and returns a plain array of 46 height ratios that is cached in the barHeights variable for the lifetime of the component. The values are not pure noise — each bar's height starts from Math.abs(Math.sin(i * 0.42)) * 0.5 + 0.3, a slow sine wave that gives the waveform gentle rises and falls like real speech, then a small seeded jitter is layered on top so adjacent bars are not identical. The seed is a plain linear congruential generator (s = (s * 9301 + 49297) % 233280) rather than Math.random(), specifically so the exact same waveform shape renders every time the component mounts — a real recording's waveform does not change shape between plays, and neither should this one.

Playback clock: requestAnimationFrame, not setInterval

Elapsed time is tracked with requestAnimationFrame rather than setInterval. Each frame computes dt, the delta in seconds since the previous frame timestamp, and adds it to elapsed — this makes the timer resilient to dropped frames or background-tab throttling, because it is driven by actual elapsed wall-clock time between frames rather than assuming each tick represents a fixed interval. setInterval timers drift under load; a dt-based rAF loop stays accurate even if the browser skips frames.

Progress-based recoloring: percentage maps to bar count

The core visual trick is in updateUi(): elapsed / DURATION gives a 0-to-1 playback percentage, which is multiplied by the total bar count and rounded to get playedCount — the number of bars, counting from the left, that should show the "played" indigo color. A single loop over all .bar elements toggles the .played class on any bar whose index is less than playedCount. This is deliberately class-based rather than inline-style-based so the actual color transition is handled by a CSS transition: background 0.08s linear rule, keeping the JavaScript responsible only for deciding which bars are played, not for animating the color change itself.

Drag-to-seek with Pointer Events

Scrubbing uses the unified Pointer Events API (pointerdown, pointermove, pointerup) instead of separate mouse and touch handlers, which means the same code handles a mouse drag on desktop and a finger drag on a touchscreen without branching. On pointerdown, setPointerCapture is called so that pointermove keeps firing on the waveform element even if the pointer moves outside its bounding box mid-drag — without capture, a fast drag past the edge of the element would silently stop updating. seekFromClientX converts the pointer's horizontal client coordinate into a 0-to-1 fraction of the waveform's width using getBoundingClientRect(), multiplies by DURATION to get the new elapsed time, and calls the same updateUi() function playback uses — so dragging and automatic playback both funnel through one rendering path, guaranteeing the bars never fall out of sync with the displayed time.