Skip to main content
Menu

Methodology

Last updated: October 6, 2026

What a browser can and cannot measure

TestrHub tests use the standard features that every modern browser offers to websites: graphics, audio, input events, sensors, storage and network requests. These features are powerful, but a web page never talks to your hardware directly. Your operating system, its drivers, power settings and the browser itself all sit in between.

That is why we describe what each test really measures, show its limits next to the result, and never present an estimate as an exact hardware measurement.

Indicative results

Benchmarks and performance measurements run inside the browser. Their results depend on the browser and its version, extensions, other open tabs, battery or power-saving mode, and even the temperature of your device.

They are useful to compare runs on the same device, before and after a change. They are not suitable for certifying hardware or comparing it with a manufacturer’s specifications. Every benchmark result on TestrHub is labelled indicative for this reason.

Screen tests

Screen tests display full-screen colours and patterns. Some problems, such as dead or stuck pixels, can only be judged by your own eyes, and the test helps you look in the right place.

  • Colours are shown through your operating system’s colour management and your screen settings. A browser cannot calibrate a screen. The screen colour test is a visual check: its results are your own answers. The gamma step relies on a physical fact, that one-pixel black and white lines send out half the light of white, so the grey square that matches them gives the gamma. The wide-colour step draws a disc in a colour outside the standard range: it can only be seen when the screen, the system and the browser all pass wide colours on.
  • Dead pixels are counted from the marks you place yourself: the result is what you reported, never a measurement. The pixel count of your screen is the size the browser reports multiplied by its pixel ratio. The tolerance shown is the one often called Class II (per million pixels: 2 bright, 2 dark, 5 stuck sub-pixels); it is indicative, because each manufacturer sets its own policy.
  • Refresh rate is estimated from how often the browser draws a new frame. This usually follows the screen’s refresh rate, but battery saving, variable refresh rate technologies or a busy device can lower it, and some browsers limit pages to 60 frames per second whatever the screen. The refresh rate test times the frames for five seconds, takes the usual interval between two frames as the length of one frame, and divides the total time by the number of frames it should contain. A frame that arrives after 1.6 times that length or more is counted as skipped. The closest standard rate is named when the measurement is within 2% of it. The result is indicative.
  • Screen resolution is worked out, not read: a browser reports the size websites work with and a pixel ratio, and the real pixel count is one multiplied by the other. With fractional scaling the browser rounds its figures, so the test brings the product back to a resolution that screens are really built with when one is within three pixels, and says “about” otherwise. Browser zoom changes the pixel ratio and cannot be read directly: the test looks for its usual signs and warns when it suspects it. The native-resolution check is a visual check: the result is what you reported. Pixel density is computed from the diagonal you enter, because a browser cannot know the physical size of a screen. Some browsers hide the real screen size to protect privacy.

Keyboard, mouse and touch tests

The browser receives key presses, clicks and touches after your operating system has processed them.

  • Some keys never reach a web page: the Fn key, some media keys, and shortcuts reserved by the system.
  • Timings are measured with the browser clock, whose precision is slightly reduced by browsers for privacy and security reasons.
  • A test can show that an input works now. It cannot predict how long a switch or a screen will last.
  • The mouse test counts a press as an unwanted double click when it comes less than 80 milliseconds after the previous press of the same button, or less than 25 milliseconds after its release. The polling rate is an indicative estimate: it counts the movement reports the browser passes on while the mouse moves without pause, and the browser may limit them.
  • The click speed test divides the clicks by the length of the test. The fastest second is the most clicks within any one-second window. The rhythm is the standard deviation of the gaps between clicks divided by their average. Two mouse presses less than 15 milliseconds apart are flagged as a probable double click from the switch; gaps that vary by less than two milliseconds over twenty clicks or more are flagged as a probable automatic clicker. Both flags are hints, not proof.
  • The gamepad test reads the controller through the browser’s Gamepad API once per screen refresh. Stick values are the raw positions, before the dead zone a game applies. Drift is the largest distance from the centre over five seconds without touching the sticks (the first 0.4 seconds are ignored); the suggested dead zone is that value plus three points, never under 5%. Range is the farthest point reached in each of 36 directions, and the weakest direction is reported. A browser cannot measure a controller’s input lag.

Audio, camera and sensors

Tests that use your microphone, camera or motion sensors only start when you ask them to, and your browser asks for your permission first. The audio, video and sensor data are processed on your device and are not recorded or sent to us.

Sound played by speaker tests goes through your system mixer, so audio enhancements, equalisers or spatial sound settings can change what you hear.

The audio frequency test generates its tones with the browser’s own oscillators; square and sawtooth waves are played at half and 60% of the level of a sine so that they sound about as loud. Its guided checks play fixed lists of tones (125 Hz down to 20 Hz, and 8 kHz up to 20 kHz) at the volume you set with a 1 kHz reference, and stop at your first “No”: the result is the last tone you heard. It describes your equipment, your volume and your ears together. It is indicative, and it is not a medical hearing test. Downloaded files are 16-bit stereo WAV at 44.1 kHz, 6 dB below the maximum level.

The vibration test uses the browser’s Vibration API, which can only switch the motor on and off for set lengths of time: it cannot set the strength, and it cannot tell whether the motor actually moved. Its results are your answers to four vibrations (1 second, 40 milliseconds, six pulses of 80 milliseconds, and 5 seconds). The page decides what your device can do from the browser’s features: iPhones and iPads do not offer the Vibration API, and a device whose main pointer is a mouse or a trackpad is treated as a computer, without a motor.

The sensor test reads the browser’s motion and orientation events, which carry processed values (some browsers round them slightly, to 0.1 m/s², 0.1 °/s or 0.1°, to protect privacy). A device counts as having a sensor only once it sends a real value: computers send empty events. In the flat and still check, the first second is ignored and the next five are averaged: gravity is the length of the average acceleration, noise is the typical spread of the readings (a spread over 0.6 m/s² means the phone moved, and the check is refused), and the gyroscope at rest is the average rotation speed. The level is measured twice, the phone turned half a turn in between: half the sum of the two tilts is the sensor’s own offset, half the difference is the table’s slope. In the movement check, a direction responds when its angle changes by 30° (45° for turning flat) or its rotation speed reaches 30 °/s. In the compass turn, the heading must reach 34 of the 36 sectors of 10°; a change of more than 30° between two readings counts as a jump. All these results are indicative.

Microphone levels are indicative. They are measured on the signal your browser receives, after your system’s input volume and any voice processing, and are expressed relative to the loudest sound the microphone can record (0 dB is that maximum, so values are negative). They are not the decibels of a sound level meter. The voice level is the level reached during the loudest tenth of the speaking phase, the background noise is the typical level of the quiet phase, and clipping is the share of moments where the signal hit the maximum.

Camera values are indicative too. The resolution is the size of the images your browser receives, which can be lower than the camera’s maximum (the browser, a USB hub or another app can limit it). The frame rate is counted on the images really delivered during three seconds; where a browser cannot count them, the test shows the rate reported by the camera and says so. Lighting is judged from the average brightness of a reduced copy of the picture, and from the share of very dark and very bright areas: it describes the image, not the light in the room.

Internet tests

Internet tests need a server to talk to. They connect directly from your browser to the external service named on the test page, over HTTPS.

  • Results depend on the distance to that server, your Wi-Fi quality and other devices using your connection at the same time.
  • Latency is measured with web requests, not with the ICMP “ping” used by command-line tools, so values can differ slightly.

What we never do

  • We never invent a value. If something cannot be measured in your browser, the result says so.
  • We never upload your files or your test results. A result is only shared when you choose to copy its link or download its image.
  • We never show an estimate as a certified measurement.

Found a problem?

If a result looks wrong on your device, please tell us which test, browser and device you used. It helps us improve the tests for everyone.