h5ECG: A Canvas Rendering Library That Draws Real ECG Paper, Not Just Curves
Most charting libraries treat ECG data as generic time-series lines, ignoring the strict calibration, grid ratios, and multi-lead layouts that make a waveform clinically legible. h5ECG offloads that domain-specific rendering so frontend teams building health dashboards or diagnostic viewers don't reinvent a fragile, incorrect ECG paper from scratch.
Drawing a medical-grade ECG waveform on the web requires more than connecting data points with a line. Raw values from acquisition devices must be calibrated from ADC units into millivolts, then plotted against a grid where speed and gain dictate the physical meaning of every millimeter. h5ECG handles this entire pipeline, from data calibration and multi-lead layout to pixel-bucket peak preservation during zoom.
The library ships with native, React, and Vue entry points. It supports standard 12-lead layouts like 3x4 and 6x2 in both synchronous and continuous modes, and a draggable ruler returns duration, voltage, and heart rate estimates directly from the rendered waveform. Grid and waveform layers are drawn separately, and only visible samples are processed to keep rendering performant.
A live demo and source are available on GitHub. The project is actively maintained and accepts contributions, with the author committing to fold real-world performance and data-adaptation fixes back into the repository.
ECG rendering sits at an uncomfortable boundary where frontend convenience and medical correctness collide; getting the units wrong produces a waveform that looks plausible but is clinically meaningless.
Preserving peak-valley extrema during downsampling is a deliberate choice that prioritizes diagnostic signal integrity over smooth anti-aliased lines, which is the opposite of what most charting libraries optimize for.
The library's calibration defaults are tied to one specific device's ADC parameters, which means every adopter must consciously override them — a design that forces correctness rather than hiding it behind a magic black box.
A question: for data like EEG, you often need real-time observation, meaning continuous rendering of the latest data (say, sampling every 10ms). With charts needing frequent updates (and the data volume still being large, e.g., 5000 samples), would that cause lag? And if a page renders multiple charts simultaneously, each with the same large data volume and update frequency, can it hold up?
worker
But workers can only handle computation; they can't solve the rendering problem. My main concern here is still the frequent rendering of large data volumes.