How Device Bench tests its browser instruments.

What the browser can measure

Key events, gamepad button and axis arrays, and digital microphone samples come directly from browser interfaces. A camera track can report its configured width, height, and frame rate; the fullscreen interface can report whether the document entered fullscreen. These values are reported: the browser or operating system supplies them, and the page does not measure them independently.

The page calculates other values from observations over time. For clicks per second, it divides the click count by measured elapsed time. A microphone level comes from calculations on a window of samples. Refresh-rate estimates use intervals between animation frames, while pitch estimates use periodic structure in a sample window. These are measured values. The page performs the calculation, prints the units, and explains the limits that can affect the result.

Some checks still need a person's judgment. A camera preview does not tell the browser whether the picture looks acceptable at the far end of a call. It can render a red field or report that a speaker channel played, but it cannot see the light from the panel or know whether the listener heard the intended side. Those rows are confirmed by you. The page never silently treats those confirmations as browser measurements.

How results are checked

Each result names the input it uses and the operation applied to it. Time-based tools calculate elapsed time from timestamps rather than assuming callbacks run on schedule. Audio instruments use digital full-scale units; an uncalibrated microphone cannot serve as a sound-level meter. Device tests keep raw states available long enough to explain a summary, including individual keys, axis values, inspected audio windows, detected frame intervals, and the separate confirmations in a call check.

Automated checks cover each tool's main function and at least one refusal or error path. Controlled key sequences, signals, timer transitions, and geometry give deterministic engines known inputs with known expected results. Structural checks compare the numbers in explanatory copy with the engine's constants. A threshold change without a matching explanation fails those checks. Separate checks in real Chromium cover security policy and visual behavior that a simulated document cannot observe.

Missing evidence must lead to a refusal. The microphone page reports insufficient signal below its stated floor, and the pitch tool reports no steady pitch when the signal is not periodic enough. If a browser does not expose a capability, the readout says it was not reported. The tool must not substitute a blank, a guessed edge value, or a reassuring “pass” for the missing evidence.

How privacy is enforced

Device Bench is a static site. There is no account system, upload endpoint, analytics collector, or database behind a test. Keyboard events, microphone samples, camera frames, gamepad states, and generated results remain in the page that received them. Closing or reloading that page discards them unless a tool explicitly stores a harmless preference, such as a local calibration, in browser storage.

Microphone and camera access begin only after a person presses the relevant control and the browser grants permission. The page does not request either capability on load. The live security policy allows scripts and network connections only from this site, blocks third-party script origins, and prevents embedded objects and framing. Cloudflare necessarily receives ordinary page requests to deliver the HTML, styles, and scripts, but it does not receive the key presses, audio samples, camera frames, or test results processed after the page loads.

The privacy page explains the hosting boundary. The site's implementation keeps tests local, while the response header restricts where code can connect. The test suite checks both the repository policy and the policy served with the site.

Browser and hardware limits

A key event can identify the physical key position reported by the browser, but firmware-handled keys may never reach the page. Gamepad axes are controller output values, not millimeters of stick travel. Camera settings may describe the configured stream rather than the sensor's native mode; a device-pixel ratio may describe a scaled framebuffer instead of the panel itself. Device Bench reports these browser-visible values without treating them as hardware specifications.

Permissions, drivers, operating-system processing, Bluetooth modes, browser throttling, display scaling, and room conditions can affect a result before it reaches the page. Each tool explains the limits relevant to its measurement. It describes how to repeat a measurement when that would reduce uncertainty, or says when you need another device or a repair professional to settle the question.

Published verdict thresholds

Nine instruments on this site classify a measured value into three published bands: PASS, CHECK SETTINGS, or LIKELY FAULT. The band sits next to the number it describes, on the page that measured it. CHECK SETTINGS always sits between the other two; nothing skips it by construction.

The FPS / Frame Rate Test counts dropped frames (intervals over three times the run's median) as a share of the sample, rounded to a whole percent. A rounded 0% is PASS. 1–2% is CHECK SETTINGS: background load, a throttled tab or a power-saving mode can cause a small drop rate. 3% or more is LIKELY FAULT, consistent with sustained load or a display or graphics-driver problem rather than one brief stall. It is a percentage, not a count, because the sample length varies with how long the test runs.

The keyboard tester judges chatter and stuck keys. Chatter is one key registering twice under 30 ms apart, too fast for two deliberate presses. On the worst key, 0 chatter repeats is PASS. 1–2 is CHECK SETTINGS, since one bounce can happen on a clean switch. 3 or more is LIKELY FAULT. A stuck key is one reported held with no release: held for 5 s or more is CHECK SETTINGS, since a deliberate hold looks the same; held for 15 s or more is LIKELY FAULT. The worse of the two is the verdict; keys that never register do not change it.

The key rollover and ghosting test runs five preset combinations (WASD + Space + Shift, W + A + Space + Shift, W + D + Space + Shift, Q + W + E + R, and ↑ + ← + Space). A key counts as blocked only when every other key of the combination was held at once and the missing key has registered on its own in the same session. A possible ghost is a non-modifier key outside the combination reported while three or more of its keys are held; it may be a brushed neighbour, and the page says so. Over the presets, 0 combos with a blocked key or a possible ghost is PASS. 1–2 combos is CHECK SETTINGS, since a key not pressed fully looks blocked. 3 or more combos is LIKELY FAULT.

The microphone test classifies the median speech level from a two-window probe (four seconds quiet, four speaking), in dBFS. −30 to −12 dBFS, with the speech median at least 10 dB above the quiet median, is PASS. Quieter than −30 dBFS is CHECK SETTINGS: the page shows the input-gain steps for the detected operating system, re-measures and prints the before and after. Still quieter than −30 dBFS on that re-measure is LIKELY FAULT. Louder than −12 dBFS, or a difference under 10 dB, is CHECK SETTINGS. No audio is recorded or uploaded.

The webcam test takes grain as the median of each pixel's frame-to-frame luma deviation over ten frames from a centre crop; in a still scene only sensor noise changes a pixel. If more than a quarter of the pixels move by over 20, the read is withheld. Grain of 2.5 or less is PASS, up to 6 is CHECK SETTINGS, and above 6 is LIKELY FAULT when the mean brightness is 80 or more, or CHECK SETTINGS in a dimmer scene, because a dim room raises gain and gain is grain. Resolution of 720 lines or more on the short side, and 24 fps or more, are PASS; less is CHECK SETTINGS. The worst of the three sets the verdict. Frames stay on the device and are dropped after the calculation.

The left/right speaker test knows only which channel it played; you report where you heard it. Each side heard where it was played is PASS. A swap, both sides (mono), or nothing on either side is CHECK SETTINGS. One side heard correctly while the other gives nothing is LIKELY FAULT in the silent side's path. The verdict restates your report.

The dead pixel test cannot see your screen, so it reads your own clean or defect answer for each of its six screens (white, black, red, green, blue, 50% gray) and gives no verdict until all six are judged. Fault states, in order: a mark on both white and black is on the glass, CHECK SETTINGS, because a pixel fault vanishes on one of them; clean the screen and re-run. White but not black is a dead pixel, black but not white a stuck or hot pixel, and red, green or blue without either a subpixel fault: each is LIKELY FAULT. 50% gray alone is a dim pixel or mura, CHECK SETTINGS. No mark on any screen is PASS. A result saves as a PNG tag or a #dp= link (one letter per screen: c clean, d defect) that re-opens it on the device.

The mouse button test and the gamepad tester publish the same three-band verdict beside their own numbers, with thresholds stated on their own pages; they are not restated here, so the numbers cannot drift from the pages that measure them.

Corrections and revisions

Guides show who published them and when they were last reviewed. Their source sections point to the standards or platform documentation that support factual claims; the prose remains Device Bench's own explanation and measurement. A changed claim receives a new reviewed date. Dates are not refreshed merely to make a page look current.

When a tool disagrees with its explanation, both need to be corrected together. To report the problem, include the page URL, browser and operating system, the value shown, what you expected, and the shortest sequence that reproduces it. You do not need to send personal test data. Report a correction or measurement problem.