Controller and screen tests
Two kinds of hardware you argue with rather than about. Both give a number here: a drift score with a threshold, and a refresh rate measured from frames the browser was actually handed.
Dead pixel test
Before you count the spots on your screen, there is one step almost everybody skips.
Gamepad tester
Every button, every axis, live โ with the number behind the dot, not just the dot.
Refresh rate test
Your monitor is set to 144 Hz. Whether it delivers 144 is a different question.
Screen resolution
The browser says 1707 by 960. The box said 2560 by 1440. Both are telling the truth.
Stick drift test
A dot that wanders is not a verdict. Ten seconds of measurement is.
Touch screen test
Ten fingers, one panel. Most screens stop counting long before you run out.
A controller and a monitor fail in the same frustrating way: gradually, and always with someone willing to tell you it is in your head. The camera creeps left when nobody is touching the stick. The screen feels no smoother than the old one. Both arguments end the moment there is a figure on the table, which is what this group produces.
For the controller, start with gamepad tester to confirm every button and axis is answering and correctly mapped โ a controller that seems broken is often just presenting a different layout than the game expects. Then run the stick drift test, which samples both sticks at rest with no deadzone applied and turns the result into a score with a stated threshold. That distinction is the whole point: a game’s deadzone can mask real drift for months, so the only honest measurement is one taken without it.
For the display, the refresh rate test reports the rate the browser was actually handed and the matching frame time in milliseconds, which is how you catch a 144 Hz panel quietly running at 60. Screen resolution shows the CSS pixels, the device pixel ratio and the physical pixels together, so a scaled display stops being confusing. The dead pixel test fills the screen with flat colours โ the only reliable way to find a single failed dot โ and includes a cycling mode that sometimes frees a stuck one. The touch screen test covers the same ground for panels you press instead of look at: which points register, how many at once, and whether any area has stopped responding.
Frequently asked questions
How much stick drift is still normal?
A stick at rest should report values hovering within a few hundredths of zero. Movement past that with your hands off the controller is drift, and once it is large enough to move a camera or a cursor on its own, it will not settle down again โ potentiometer wear is one-directional. The drift test turns the resting deviation into a score so you can compare the same stick a month apart instead of relying on how it felt last time.
How is drift different from a deadzone?
A deadzone is the game’s answer to drift: it ignores small stick values so a slightly worn stick still behaves. That is why a controller can be visibly drifting here and feel fine in one game and unplayable in another โ the games are applying different deadzones to the same signal. This test deliberately applies none, which is the only way to see what the hardware is really sending.
Is it a dead pixel or a stuck one?
The colour tells you. A pixel that stays black on a white screen is dead โ its transistor has failed and there is nothing to revive. A pixel showing a fixed red, green, blue or white dot on a black screen is stuck: the subpixel is jammed on rather than broken off. Run the test twice, once on white and once on black, and the difference is obvious.
Can a stuck pixel be fixed?
Sometimes, and the odds are better the newer the fault. Cycling colours rapidly over the area exercises the subpixel and occasionally frees it, which is why this site includes a cycling mode; leave it running for a quarter of an hour or so. It does nothing for a genuinely dead pixel, and there is no software that can โ that one is a panel replacement or nothing.
Why does my 144 Hz monitor test at 60 Hz?
Because the browser measures the frames it was actually handed, and something upstream is capping them. The usual causes are a cable or port limited to 60 Hz at your resolution, a display setting still on the default rate, browser hardware acceleration switched off, or a laptop on battery in a power-saving mode. Change one at a time and re-run โ the reading is the fastest way to find out which one it was.
Why does the resolution here not match my display settings?
Because they are two different measurements. The browser reports CSS pixels, and your operating system’s scaling multiplies them: at a device pixel ratio of 2 a 2,560-pixel-wide panel reports 1,280 to the page. Neither figure is wrong, which is why both are shown side by side along with the ratio between them, and the physical width is the two multiplied together.
How the test works
requestAnimationFrame timestamps, so the figure is the rate of frames the browser was actually
handed and can legitimately be lower than the mode your display is set to; frame time in
milliseconds is 1,000 divided by that rate. Resolution is reported twice โ in CSS pixels as the
page sees it and multiplied by the device pixel ratio for the physical count โ because on a scaled
display those are different numbers and only one of them is what the panel has. The pixel tests are
visual by design: full-screen flat colours are the only reliable way to find a single failed dot.Sources: