DeviceRecheck provides six browser-based checks: keyboard, mouse, dead pixels, webcam, headphones and speakers, and microphone. It helps you describe a problem, observe what happens, change one condition, and repeat the same task. Results describe the current test environment; they do not diagnose hardware failure or certify a device’s overall condition.
What DeviceRecheck does
DeviceRecheck is the brand responsible for maintaining this service and its explanatory content. The tools are intended for everyday troubleshooting, checking a newly connected device, and preparing for a call. Technical users can also use them to collect basic observations before investigating further.
The keyboard test displays received presses, releases, held combinations, and automatic repeats. The mouse test records button activity, scrolling, and click intervals. The dead pixel test supplies black, white, red, green, and blue backgrounds for visual inspection. The webcam test provides an active preview and input selection. The headphone and speaker test plays left, right, and both channels. The microphone test shows relative input activity and offers short recording and playback when supported.
Choose the check that matches the symptom. For example, use the microphone test when others cannot hear you, the output test when you cannot hear them, and the webcam test when your picture is missing. These are separate tasks: success in one does not establish that the others work.
Test methods and technical references
DeviceRecheck’s methods draw on public browser API documentation and practical device-testing workflows. The explanations distinguish events received by the page, media access and playback states, and observations you supply. Public documentation explains the browser mechanisms; it does not certify this website or establish that every device and browser combination has been tested.
The KeyboardEvent.repeat property identifies an event generated while a held key is automatically repeating. [KeyboardEvent: repeat property - Web APIs | MDN]
That distinction matters when investigating extra input: holding a key and deliberately pressing it several times are different test tasks. Use MDN’s KeyboardEvent.repeat reference for the underlying definition.
Access to camera and microphone inputs through getUserMedia requires user permission. [MediaDevices: getUserMedia() method - Web APIs | MDN]
A getUserMedia permission request can remain pending if the user does not make a choice. [MediaDevices: getUserMedia() method - Web APIs | MDN]
See MDN’s getUserMedia reference for media access, secure-context requirements, and error conditions. Waiting for permission, denied access, and no matching input are different outcomes; none should be treated as a completed hardware test.
MediaRecorder.isTypeSupported reports whether the current browser supports a specified recording MIME type. [MediaRecorder - Web APIs | MDN]
The MediaRecorder documentation explains recording and format checks. An unavailable recording format should be understood separately from whether microphone input can be obtained.
Our editorial standard is to connect each instruction to a specific task, explain what the observation supports, and give a useful next step. Suggested causes remain possibilities unless further checks distinguish them. DeviceRecheck makes no claim of professional review, laboratory calibration, or certification.
What you need to look at and listen for
For the dead pixel test, inspect the same area on each background and describe any persistent point by location and appearance—for example, “small dark point near the upper-right corner, visible on white and green.” Check the visible colored area only. Browser bars, controls, and other uncovered areas are outside that inspection. The page does not automatically identify or repair pixels.
For the webcam test, confirm that the preview comes from the intended camera and shows the picture you expect. Describe a black image, frozen motion, poor framing, or an unclear picture separately. Obtaining a stream is a browser observation; deciding whether its picture is usable requires looking at it.
For headphones and speakers, start with low system volume and listen to each target channel. Record where you actually hear sound: left, right, both, or neither. A playback state alone does not establish what reached your ears. Select the intended output in your system settings, and stop if the sound is uncomfortable.
For the microphone test, watch for a response while speaking, then listen to a short recording if playback is available. Describe intelligibility, interruptions, and unwanted sound in your own words. Treat the displayed level as a relative activity indicator rather than a calibrated loudness or audio-quality score.
For keyboard and mouse checks, compare your physical actions with the event log. Note whether you tapped or held a key, which mouse button you used, and whether an apparent extra event occurred during a deliberate single action. Your description supplies context that an event count alone cannot provide.
How to compare a first run with a retest
Start with a repeatable task and save the first run as your baseline. A useful task is specific: “press and release A five times,” “make ten separate left clicks,” or “say the same sentence at the same microphone distance.” Include the selected device and relevant settings in the task description.
Change one condition, write down the adjustment, reset the current observations, and repeat the task. For example, reconnect a mouse to another USB port while keeping the button, click count, and pace the same. Compare the first run with the latest retest, including your feedback and the recorded adjustment.
Interpret a change narrowly. If microphone activity appears after selecting another input, the observation is that the newly selected input supplied a signal in this test. It does not prove that the original microphone is broken. If nothing changes, record “same result under the tested conditions” rather than concluding that the adjustment could never help.
Changing the device, browser, task, speaking distance, or listening volume changes the comparison. Label that change explicitly. A test in a second browser can help investigate where a symptom appears, but it is a separate environment rather than a controlled hardware benchmark. Do not rank microphone quality by meter height or mouse quality by a single click interval.
Missing observations remain missing. A run with no listening feedback cannot establish that audio sounded correct, and an unanswered permission request cannot establish that the camera failed.
Can a browser check diagnose hardware failure?
No. Use DeviceRecheck to establish what happened during a particular task and to choose the next troubleshooting step. A successful preview, received key event, or audible channel is useful evidence about that run; it is not a complete health assessment.
Browser and operating-system shortcuts can reserve keys, and a laptop’s Fn key may not be exposed to a web page. [Keyboard Test – Free Online Keyboard Tester]
For a missing key, release all keys, reactivate the test area, and repeat a simple press-and-release task. Then compare the affected key in another application. For suspected mouse double-clicking, repeat deliberate single clicks and compare the behavior in another application before drawing a hardware conclusion.
For camera or microphone access problems, check the selected input and the browser’s site permissions before repeating the test. If a device works here but fails in a meeting app, test that app’s selected device and permissions next. The browser result narrows the investigation; it does not rule out intermittent problems or establish that the entire device and driver path is fault-free.
Keep a short record for further help: the device, browser, task, expected behavior, actual observation, adjustment, and retest result. If the symptom persists across applications or computers, share those reproducible observations with the manufacturer or a repair service. DeviceRecheck does not provide hearing tests, professional acoustic measurements, display calibration, or repair certification.
Support and privacy contact
Contact DeviceRecheck at [email protected]. Include the page, browser and steps when reporting a problem. Avoid sending passwords, private recordings or identity documents.