How Device Bench tests its browser instruments.

What the browser can measure

Some values arrive directly from a browser interface. A keyboard page receives key events. A gamepad page receives arrays of button and axis values. A camera track can report the width, height, and frame rate at which the browser configured it. A microphone stream supplies digital samples. A fullscreen page can ask whether the document actually entered fullscreen. Device Bench labels these values as reported when the browser or operating system supplied them and the page did no independent measurement.

Other values are derived from observations over time. Clicks per second are counted clicks divided by measured elapsed time. A microphone level is arithmetic on a window of samples. A refresh-rate estimate comes from intervals between animation frames. Pitch is an estimate from periodic structure in a sample window. These are measured values: the page owns the calculation, prints the units, and publishes the limits that can move the answer.

A third category belongs to the person using the tool. A browser can show a camera preview but cannot know whether it looks acceptable to the far end of a call. It can render a red field but cannot see the light leaving the panel. It can report that a speaker channel played but cannot know whether the listener heard it on the intended side. Those rows are confirmed by you, never silently promoted into browser measurements.

How a result earns its place

A result starts with a named input and a named operation. Time-based tools use elapsed timestamps rather than assuming that callbacks arrive on schedule. Audio instruments print digital full-scale units rather than presenting an uncalibrated microphone as a sound-level meter. Device tests retain raw states long enough to show the evidence behind a summary: individual keys, axis values, inspected audio windows, detected frame intervals, or the separate confirmations that make up a call check.

Each tool has automated coverage for its central job and for at least one refusal or error path. Deterministic engines are exercised with controlled inputs so a known key sequence, signal, timer transition, or geometry produces a known result. Structural checks compare numbers in explanatory copy against the constants the engine actually uses, so changing a threshold without changing its explanation is a failing change. Real Chromium separately checks security policy and visual behavior that a simulated document cannot observe.

The important rule is refusal. If the microphone signal is below the stated floor, the page says there is not enough signal. If a pitch is not periodic enough, it says there is no steady pitch. If a browser does not expose a capability, the readout says it was not reported. A blank, a guessed edge value, or a reassuring “pass” is not an acceptable substitute for 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.

This distinction matters: “runs locally” is a property of the implementation, not a badge added to the copy. The privacy page names the hosting boundary, the response header constrains what code can connect elsewhere, and the test suite checks both the repository policy and the policy served on the wire.

Browser and hardware limits

Browser interfaces are abstractions. A key event can identify the physical key position the browser reported, but some firmware-handled keys never reach a page. Gamepad axes describe controller output values, not millimeters of stick travel. A camera setting may be 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 the layer it can actually observe and avoids relabeling it as a hardware specification.

Permissions, drivers, operating-system processing, Bluetooth modes, browser throttling, display scaling, and room conditions can all change a result before the page sees it. That is why each tool has its own limits section rather than inheriting a generic disclaimer. Where repeating the measurement reduces uncertainty, the page says how. Where only a second device or a repair professional can settle the question, the page says that instead.

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.

If a tool and its explanation disagree, the instrument wins only long enough to expose a defect: both need to be corrected together. Reports should include the page URL, browser and operating system, the value shown, what was expected, and the shortest sequence that reproduces it. Personal test data is not needed. Report a correction or measurement problem.