What this suite is for
Use it when an input, camera, microphone, speaker, display or game controller behaves unexpectedly. Each tool isolates one task so the page can stay useful without an account, installer or remote processing service. Start from the 18 browser hardware tests, or read one of the 14 guides when you want the reasoning before the measurement.
The question every tool here is built to answer is narrow on purpose: is the device sending the browser what it should be sending? That is a smaller question than “is my hardware broken”, and keeping the two apart is what makes a result worth acting on. A mouse that reports every click cleanly in this tab has ruled out one large class of fault, and the page says exactly that instead of declaring the device healthy.
Who maintains it
probekits is built and maintained by a small independent team of web engineers. It is not affiliated with any hardware manufacturer, retailer, repair service or warranty programme, and no tool result is influenced by who made the device you are testing. The site carries advertising to cover hosting; advertising has no input into which tools exist, what a tool reports, or which verdict a run produces. If a result looks wrong, write to us and say so — the contact page lists what to include so a report can actually be reproduced.
How a tool gets written
Every tool starts from a browser API that can observe the signal honestly — pointer and keyboard events, the Gamepad API, the Web Audio graph, and a live media track together with the settings the browser actually negotiated for it. Where the browser adds latency of its own, the tool measures the full path it can actually see and names it as such: a click-to-paint number includes event dispatch, JavaScript, layout and compositing, so it is reported as click-to-paint rather than as device latency. Where a browser cannot resolve something — a report rate above roughly 2000 Hz, an independent 5.1 channel, a controller’s own polling interval — the tool says so on the page instead of printing a confident number.
Results are stated as a plain sentence first, then the measurements that produced it, then the limits of the run. Repeated timing checks report a median and a tail rather than one best-case figure, because a single sample from a browser is not repeatable enough to compare. Each tool is covered by automated tests that drive it the way a person would, including the failure paths where permission is denied or a device disappears mid-run.
Four operating principles
Runs locally
Measurement code runs in this tab. Hardware streams and readings are not sent to a server.
A verdict comes first
Each completed test returns a plain conclusion before the supporting measurements.
Limits stay visible
Timing and polling estimates state their browser scheduling margin instead of claiming device-level precision.
Hardware signals only
The suite reports browser-observed device behaviour and does not extend beyond that scope.