How Accurate Are Browser-Based Hardware Tests?

Every tool on this site runs inside your browser, not as native software. That has real implications for what can and can't be measured precisely. Here's exactly how each test works, and where the limits are.

The Short Answer

Browser-based tests are reliable for detecting problems and comparing results — a dead key, an inconsistent mouse, or a monitor stuck at the wrong refresh rate will show up clearly. What they can't do is replace a hardware-level utility for verifying an exact peak spec number, because the browser only ever sees what the operating system hands it, several layers removed from the device itself.

Why a Browser Can't Talk to Hardware Directly

Web pages run in a sandbox for security — a website has no permission to query your keyboard controller, mouse sensor, or monitor's EDID data directly. Every number these tools show is derived from timing events, not from reading hardware registers. That's true of virtually every browser-based tester, not just this site.

Keyboard: the path from finger to screen

Physical key → Keyboard controller → OS → Browser keydown/keyup event → Timer

The keyboard tester measures the time between keydown and keyup events using performance.now(), a high-resolution timer. This captures how long you held the key plus any delay the OS and browser introduced — it does not (and cannot) read the keyboard's actual internal scan rate, which is a fixed hardware spec baked into the controller.

Mouse: coalesced events and polling

Mouse sensor → USB report → OS input stack → Pointer Events API → Browser

The mouse tester uses the getCoalescedEvents() API, and pointerrawupdate where supported, to recover as many individual hardware reports as possible from each browser paint cycle. This is meaningfully more accurate than a naive mousemove counter, but it still inherits a ceiling: once your mouse's real polling rate goes much above roughly 1500–2000Hz, OS-level event coalescing starts merging reports before JavaScript ever sees them.

Monitor: requestAnimationFrame and vsync

Display panel → GPU vsync → requestAnimationFrame callback → Timer

requestAnimationFrame() is called by the browser in sync with your display's vertical refresh, so timing the gap between consecutive calls gives a genuinely accurate live Hz reading — typically within ±1–2Hz under normal conditions. What it's sensitive to is anything that delays the callback: background tabs, high CPU load, or OS-level frame pacing, which is exactly what the stability grade on the monitor test is designed to catch.

Measurement Confidence, By Test

Not every reading carries the same level of certainty. Here's how we'd rate each one:

Keyboard — is a key registering at all High confidence

Keyboard — exact scan rate in Hz Not measurable in-browser

Mouse — polling rate up to ~1500Hz High confidence

Mouse — polling rate above ~2000Hz (4000/8000Hz mice) Browser-limited, can under-report

Monitor — live Hz via requestAnimationFrame High confidence

Monitor — true end-to-end input-to-photon latency Not measurable in-browser

What Can Affect Your Results

Background tabs and apps — competing for CPU time delays when your browser processes each event.
Power-saving mode — laptops often silently cap refresh rate or throttle polling to save battery.
Cable and port standard — HDMI 1.4, for example, can't carry 144Hz at higher resolutions regardless of what your monitor supports.
Browser choice — Chromium-based browsers (Chrome, Edge) generally expose more precise timing APIs than others.
USB hubs and wireless dongles — an extra hop can add latency or reduce effective polling consistency.

Bottom line: use these tools to catch real problems (a dead key, a monitor stuck at 60Hz, an inconsistent mouse) and to compare devices under the same conditions. For certifying an exact peak spec number on very high-end hardware, pair this with a native, driver-level utility.

Test Your Hardware

⌨️ Keyboard Tester → 🖱 Mouse Rate Test → 🖥️ Monitor Refresh Rate Test →

Frequently Asked Questions

Can a browser measure hardware directly?

No. Browsers deliberately sandbox web pages away from direct hardware access for security reasons. Every measurement on this site comes from timing events the operating system already handed to the browser — not from querying the device driver or controller directly.

Why do polling rate numbers sometimes read lower than the mouse's rated spec?

Above roughly 1500–2000Hz, OS-level event coalescing and browser scheduling start merging or throttling updates before JavaScript ever sees them. A mouse can be reporting correctly at 4000Hz or 8000Hz at the hardware level while the browser only surfaces a fraction of those events.

Are these tests still useful if they can't hit the exact hardware number?

Yes, for comparison and consistency checks. Testing the same device twice, or comparing two devices under the same browser and conditions, gives you a reliable relative reading even if the absolute peak number is capped by browser throttling.

Does background CPU load affect the results?

Yes. Background tabs, other applications, and general CPU load can delay when the browser processes an event, which shows up as jitter or dropped frames in these tools even though the underlying hardware is working correctly.