The Bench
Twenty-three checks for the hardware in front of you — screen, mouse, keyboard, controller, microphone, camera, speakers and connection. The page measures your machine as it loads, then tells you which tests are worth running.
- Refresh
- ····
- Resolution
- ····
- Viewport
- ····
- Pixel ratio
- ····
- Native pixels
- ····
- Colour depth
- ····
- Gamut
- ····
- Dynamic range
- ····
- Screens
- ····
- Pointer
- ····
- Touch points
- ····
- Gamepads
- ····
- Key layout
- ····
- Audio out
- ····
- Cameras
- ····
- Microphones
- ····
- Speakers
- ····
- Capture
- ····
- Connection
- ····
- Latency
- ····
- Network
- ····
- Platform
- ····
- CPU threads
- ····
- Memory
- ····
- GPU
- ····
- Storage quota
- ····
Reading your machine…
Nothing here asked your browser for permission, and no measurement left this tab. Press ? for keyboard shortcuts.
01 · Display
Panel faults, motion and colour. Run these full-screen, in a dark room, at native resolution.
02 · Input
Mice, keyboards, controllers and touchscreens: the parts that wear out.
03 · Audio
Output before ears. Prove the speakers work, then test what you can hear.
04 · Network
Latency first, throughput second. Jitter is what you actually feel.
05 · System
What the machine says it is, and what it's connected to.
What this page measured, and what it didn't
Every number in the readout above came from a standard browser API that any site can call — the same ones a game uses to size its canvas. No permission prompt fired, and nothing left your machine.
- The refresh rate is measured, not looked up. Your browser repaints once per display frame, so timing forty consecutive frames and taking the median gap gives your real rate. The median shrugs off the one-off hiccups that would wreck an average. A result within 2% of a common rate (60 / 75 / 90 / 120 / 144 / 165 / 240 / 360) snaps to it, and the raw figure stays on the readout.
- Resolution and scaling come from screen.width, screen.height and devicePixelRatio. 2560×1440 @1.25× means your system reports a 2560×1440 desktop drawn at 1.25× density — the physical panel is 3200×1800, which is the figure on the native pixels row.
- Colour gamut and HDR are CSS media queries. They report what the browser is willing to render, which is what actually reaches your eyes.
- Audio comes from an AudioContext that is opened, read for sample rate and channel count, and closed again in the same breath. No microphone is touched.
- Cameras and microphones are counted, not identified. Device names are the part that triggers a permission prompt, and this page never reads them. That's why you see “1 microphone” and not which one. Some browsers also collapse the list to one entry per kind until you grant access, so treat the counts as a floor rather than a total.
- The GPU string comes from WebGL, and some browsers deliberately mask it. If yours reads masked by browser, that is privacy protection working, not a fault.
- Nothing is stored on a server. No account, no upload, no analytics on any measurement. The numbers exist only in the tab you are looking at.
Before you trust a reading
- Background tabs are throttled. Browsers slow hidden tabs to roughly 1 fps. Keep The Bench in front while it measures.
- Battery saver caps frame rate. Laptops and phones in low-power mode routinely pin the browser at 30–60 fps regardless of the panel. Plug in and press Re-measure.
- The browser follows the display its window is on. Drag this window to the monitor you want to measure, then re-measure.
- downlink is deliberately coarse. Browsers round it to protect you from fingerprinting. For a real number, use the Internet Speed Test.
- A browser can't read everything. SMART data, temperatures, fan speeds and voltages need a native tool. Everything you can see, hear or click, a browser can test.
How to run a full check
- Start with the screen. Dead pixels and burn-in are the only faults that are permanent — find them first, especially inside a return window.
- Then motion. Refresh rate, ghosting and flicker only mean something once you know the panel itself is clean.
- Then input. A double-clicking switch and stick drift are the two commonest reasons a device gets replaced, and both take under a minute to prove.
- Then audio. Channel test first — is the left speaker even alive? — then the microphone, then the hearing test. In the other order you'll blame your ears for a dead driver.
- Finish on the network. Ping and jitter matter far more than raw throughput for games and calls. The speed test is the last thing to worry about.
- Copy the readout. If you're filing a return or asking for help, that block of text answers the first five questions anyone will ask you.
When to run which test
Just bought a monitor
Run the Dead Pixel Test and Monitor Test in the first week, full-screen, in a dark room. Dead-pixel policies have a time limit and a pixel count, and a photograph of a stuck pixel is much easier to take than to argue about later. If the panel is OLED, add the Burn-In Test.
Games feel smooth for everyone else but not you
Check the Refresh Rate Test first — a large share of 144 Hz monitors are still running at 60 Hz because nobody changed the setting. Then the Ghosting Test for pixel response, and the Screen Flicker Test if you get eye strain, which is often PWM backlight dimming rather than the game.
Your mouse clicks twice
The Mouse Double Click Test counts unintended second clicks. A switch that double-fires on more than a few percent of clicks is failing, and it only gets worse — it's the single commonest mouse fault there is. Pair it with the Mouse DPI Analyzer if the cursor also feels wrong at a sensitivity that used to be right.
Nobody can hear you
Run the Microphone Test and watch your own waveform before blaming the app: if the meter moves, the mic works and the problem is which input device the software picked. The Webcam Test does the same for video. Both count your devices first, so you know how many the browser can even see.
The game is laggy but the speed test is fine
That's the normal case — throughput is rarely the problem. Run the Ping Test and watch the jitter figure rather than the average: a stable 60 ms beats a 20 ms average that spikes to 300. The Internet Speed Test and What Is My IP fill in the rest.
FAQ
How does this page already know my refresh rate and hardware?
Standard browser APIs, all readable without permission. The refresh rate is measured by timing about forty consecutive frames and taking the median gap. Resolution and pixel ratio come from screen and devicePixelRatio, the core count from hardwareConcurrency, the GPU name from WebGL, and the camera and microphone figures from a device count that returns no names. There is no lookup, no database, and no request to a server.
Does anything here need a permission prompt?
The hub itself never asks for one — that is a design rule, not an accident. The individual tests do, but only the ones that genuinely need hardware: the microphone, webcam and screen recorder tests ask when you press start, your browser's own prompt is the gate, and you can revoke access at any time. Every other test — screen, mouse, keyboard, controller, network — needs nothing.
Why does a card say “not detected”?
Because that hardware isn't reporting to the browser right now. A controller only appears after you press a button on it — browsers deliberately hide gamepads until they're used — and a laptop with no touchscreen reports zero touch points. Those cards are drawn with a dashed outline, which in a technical drawing means “part not fitted”, but they still open and still work. Plug the device in and the card fills itself in while you watch.
Why does it say I have no camera when I do?
Some browsers hide device counts until a page has been granted access once, and privacy modes — Firefox's resist-fingerprinting, Safari's Lockdown Mode, most content blockers — can zero the count entirely. Open the Webcam Test and allow access; if the picture appears, the camera is fine and only the count was hidden.
Is a browser test as good as a real diagnostic?
For faults you can see or hear, yes: a dead pixel, a double-clicking switch, a drifting stick, a dead speaker channel and a flickering backlight all show up identically in a browser. What a browser cannot do is read SMART data, temperatures, fan speeds or voltages — for those you need a native tool.
Are these results good enough for a warranty claim?
For visible faults, yes. Dead pixels, stuck subpixels, burn-in, ghosting and a mouse that double-clicks on one press all photograph or record clearly off these tests, and manufacturers accept that evidence. For timing claims — “my 144 Hz monitor runs at 60” — the measurement is accurate but check the obvious causes first: the operating system's display setting, battery saver, and which monitor the window is actually on.
Does anything I test get uploaded?
No. Every test runs entirely in your browser. Microphone audio, webcam video and screen recordings never leave the machine — they are played back to you from memory. The only network traffic The Bench itself makes is five timed requests to a small icon on this same domain, to measure your latency.