How we test
What runs where
Every test is JavaScript running in your browser. Audio comes from the Web Audio API, controllers from the Gamepad API, microphones from getUserMedia, screens from requestAnimationFrame and the Fullscreen API. Nothing you play, say or press is uploaded.
What a browser cannot measure
- A controller only appears after you press a button; rumble support differs by browser.
- Refresh rate is measured from animation frames and is capped when the tab is hidden or the OS limits the browser.
- Safari does not expose Web MIDI or the Vibration API. The Battery API exists only in Chromium browsers.
- Mouse polling above about 1000 Hz cannot be timed accurately from a web page.
When a test hits one of these limits, the verdict card says "could not measure" instead of guessing.
How verdicts are set
Green means nothing wrong was found, amber means something to check, red means a fault we are confident about. Thresholds (for example how much stick drift counts as a fault) are locked only after at least three runs on real hardware; until then the page says so.
How fix guides are checked
Guides are drafted, then proofread against vendor documentation for each listed platform. When The Nguyen has performed every step on a real device, the guide says "Steps performed"; until then it says "Not yet performed on a device". Steps for platforms we cannot test ourselves are marked as coming from vendor documentation.
Verified on
No real-device runs recorded yet.
Who
The Nguyen. Builds and tests every GlitchCheck tool on real devices. Writes the fix guides after doing each step. Found a mistake? Tell us.