Check your hardware in the browser
Microphone, keyboard, camera, speakers, screen and connection. Nothing to install, nothing recorded, nothing uploaded.
- No install
- No account
- Nothing uploaded
Start here — press any key. Tested: 0 of 0
Nothing pressed yet.
This check needs no permission and makes no network request. For the full explanation of what a faulty key looks like, see the keyboard tester page.
The other checks
Each one is independent. Run what you need, then collect everything on the summary page.
Microphone test
Live input level, plus which of five separate faults you have — blocked, busy, missing, silent or simply quiet.
Asks permissionCamera and webcam test
The live picture with its real resolution and frame rate, and why a working camera can still show black.
Asks permissionSound and speaker test
A clean tone in the left channel, the right channel or both — the only reliable way to find one dead speaker.
No permissionPing and latency test
Median round trip and jitter. Jitter is what breaks calls up, and most tools do not show it at all.
Makes requestsFrame rate test
Five seconds counted frame by frame, with the worst one per cent separated out — that is where stutter hides.
No permissionMonitor and dead pixel test
Six full-screen colour fields. A dead pixel is invisible on a normal page and obvious on a solid one.
No permissionWhat this site will not do
It will not record you, upload anything you produce, or claim to measure things a browser cannot see — memory errors, battery health, processor temperature. There is no speed test either, and the reason is written out rather than hidden: bandwidth testing costs money that grows with every visitor, and the numbers that actually explain a bad call are latency and jitter, which cost almost nothing. The full detail of what is stored is on the data page, with a button that erases it.
This site in numbers
Other ways to diagnose a device
| Approach | Best for | Trade-off |
|---|---|---|
| The settings panels in your operating system | Checking the device itself, independently of any browser | Spread across several screens, and they say nothing about whether the app that is failing can actually reach the device |
| The test built into your meeting app | Testing the exact path a call will use, including that app’s own processing | Available only inside that app, and it will not tell you whether a second app is holding the device |
| A vendor diagnostic utility | Laptops from one manufacturer, where the tool can reach hardware a browser cannot | Needs installing, covers one brand, and will not run on a machine you do not administer |
| This site | Anyone with a few minutes before a call who needs to find out which part is at fault | Sees only what the browser is given: the Fn key, internal sensors and network cameras are outside its reach |
When this site is the wrong tool
Where this stops being the right tool — and what to use instead.
-
You want a download speed in megabits
Measuring bandwidth means pushing tens of megabytes to every visitor. That is a real running cost, it hurts anyone on a metered connection, and dedicated services already do it well.
Next step: Use a speed test for bandwidth. Come here for latency and jitter, which are what actually explain a stuttering call.
-
You want a hearing test
A result would depend on your speakers, your volume and your room — the three things a real hearing test exists to control for. Presenting that as a hearing result would be misleading about health.
Next step: See an audiologist. The sound check here tells you about your speakers and deliberately says nothing about your ears.
-
You need to test hardware the browser cannot see
Storage health, memory errors, battery wear and processor temperature are all outside what a web page is given access to. Any site claiming to measure them from the browser is guessing.
Next step: Use your operating system’s own tools or a vendor utility. It is worth being suspicious of pages that promise otherwise.
-
Nothing on the computer works at all
If the machine has no sound anywhere and no device is recognised, the fault is below the browser — drivers, ports or the operating system.
Next step: Start with a restart and with device manager or system information. Come back here to confirm the fix.
Words used across these checks
- Permission prompt
- The browser question asking whether a site may use your camera or microphone. The answer is remembered per site, which is why a working device can appear dead on one site and fine on another.
- Secure context
- A page loaded over HTTPS, or from localhost. Cameras and microphones are only available in one; on plain HTTP the API does not merely refuse, it does not exist.
- Exclusive access
- One application holding a device so that nothing else can open it. This is the single most common reason a healthy microphone or camera reports as broken.
- Latency
- The time for a request to reach a server and come back. Distance sets it, and no amount of bandwidth reduces it.
- Jitter
- How much latency varies from one moment to the next. It is what makes voices break up, and most tools never show it.
- Local storage
- A small store inside your browser tied to one site and one device. This site keeps one line per check there, and nothing else anywhere.
- Frame rate
- How many pictures per second are drawn on screen. Below roughly 25 the eye begins to see individual steps rather than movement.
- Dead pixel
- A screen pixel that receives no power and stays dark. Distinct from a stuck pixel, which is frozen on one colour and sometimes recovers.