Testing Methodology

How the test works

The camera test uses the MediaDevices API (navigator.mediaDevices.getUserMedia()) to request access to your device's camera. When you grant permission, the browser opens a video stream from the default camera (typically the front-facing camera on mobile devices).

The video stream is rendered in a <video> element with autoplay and playsinline attributes. The test requests video with facingMode: 'user' to prefer the front-facing camera, though the browser may select a different camera if the preferred one is unavailable.

When you click "Take Snapshot", the test draws the current video frame onto a hidden <canvas> element using ctx.drawImage(video, 0, 0). This captures a still image at the camera's native resolution. The canvas is then displayed for visual inspection.

What the test detects

Whether the camera responds to browser requests, produces a visible video feed, and captures a still image. The test lets you visually assess focus quality, color accuracy, exposure, and whether the correct camera (front vs rear) is active.

What the test cannot detect

The test cannot determine the camera sensor's electrical health, measure signal-to-noise ratio, detect lens光学 defects invisible in the preview, or test camera features that require manufacturer-specific APIs (like optical image stabilization, laser autofocus, or night mode). Auto-focus and auto-exposure are controlled by the operating system, not the browser.

Environmental factors

Camera results depend heavily on lighting conditions, lens cleanliness, and whether another application is using the camera. A dirty lens can make a perfectly functional camera appear defective. Always clean the lens and ensure adequate lighting before concluding the camera has a hardware problem.

How the test works

The microphone test uses the MediaDevices API to access your audio input device. When you click "Start Recording", the browser requests microphone permission and opens an audio stream.

Simultaneously, the test creates a Web Audio API context, connects the microphone stream to an AnalyserNode with fftSize = 128, and renders a real-time frequency visualizer on a <canvas>. The visualizer displays 64 frequency bins from low (bass) to high (treble) as cyan-colored bars.

The test also creates a MediaRecorder instance to record 3 seconds of audio. The recording is stored as a Blob in device memory and played back through an <audio> element for review.

What the test detects

Whether the microphone captures audio, produces audible playback, and responds to sound input (visible in the frequency visualizer). The test confirms the microphone works at the software level and produces recognizable audio.

What the test cannot detect

The test cannot measure signal-to-noise ratio, frequency response, total harmonic distortion, or microphone sensitivity. It cannot distinguish between multiple microphones on the same device (many phones have 2-3 mics for noise cancellation). The browser selects the default input device — you cannot choose which physical microphone is used without changing system settings.

Limitations

The 3-second recording is a brief sample. Intermittent microphone issues (like a loose internal connection that only fails at certain angles) may not be captured. Bluetooth headset microphones require the HFP (Hands-Free Profile) — A2DP alone only supports audio output, not input.

How the test works

The speaker test uses the Web Audio API to generate a 440 Hz sine wave tone. The test creates an OscillatorNode, a GainNode for volume control, and a StereoPannerNode for channel isolation.

Clicking "Play Left Speaker Channel" sets the pan value to -1 (full left). Clicking "Play Right Speaker Channel" sets it to 1 (full right). The tone plays for 1.2 seconds with a quick exponential fade-out to avoid abrupt audio clicks.

The browser sends the audio to whatever output device is set as default in your OS. If you have headphones connected, the test plays through the headphones, not the phone speakers. The test does not measure what comes out of the physical speaker — it confirms the browser can produce audio on the correct channels.

What the test detects

Whether both left and right audio channels produce sound independently. If you hear audio from both sides, both speaker drivers are functional and the audio routing is correct. If only one channel works, it may indicate a failing speaker driver or incorrect audio routing.

What the test cannot detect

The test cannot measure speaker distortion, frequency response, maximum volume, or audio quality. A speaker can pass this test while still sounding distorted at higher volumes or having reduced output. The test plays at moderate volume — damage that only appears at high volume is not detected.

How the test works

The touch screen test renders a full-screen 6x4 grid (24 tiles) on an HTML <canvas> element. The test listens for touchstart, touchmove, mousedown, and mousemove events on the canvas.

When a touch or click event fires, the test calculates which grid cell the touch falls within using the touch coordinates and canvas dimensions. The touched cell changes color to cyan to indicate it has been registered. The test tracks how many of the 24 tiles have been touched.

Once all 24 tiles are touched, a results bar appears asking you to confirm whether all tiles worked or some were broken. This is a manual confirmation step — the test cannot automatically determine if a tile failed to register your touch because it relies on your visual observation.

What the test detects

Whether the touchscreen digitizer registers touch input in each screen region. By requiring you to touch all 24 tiles, the test covers the entire display area and helps identify localized dead zones where touches are not registered.

What the test cannot detect

The test cannot inspect the physical digitizer electronics, measure touch sensitivity, detect intermittent faults, or test multi-touch (use the Multi-Touch Test for that). Ghost touches (touches registering without input) are not automatically detected by the test.

How the test works

The multi-touch test renders a full-screen canvas and listens for touchstart, touchmove, touchend, and touchcancel events. Each finger placed on the screen generates a unique Touch object with a unique identifier property.

The test tracks all active touch points using a Map<number, TouchPoint>, where the key is the touch identifier. Each touch point is rendered as a colored circle with a unique ID and a trail showing its movement history.

The test displays three metrics: current active touches, maximum simultaneous touches detected, and a status badge (Multi-Touch, Single Touch Only, or Waiting). The maximum count is the key metric — it shows how many simultaneous fingers your digitizer can track.

What the test detects

The maximum number of simultaneous touch points your screen can detect and track independently. Most modern phones support 5-10 simultaneous touches. If only 1 touch is detected, the device may have older touchscreen hardware or a digitizer limitation.

What the test cannot detect

The test does not test gesture recognition (pinch-to-zoom, swipe) — those are handled by the operating system, not the browser's touch events API. A device can pass multi-touch detection but still have gesture issues due to OS settings or software bugs.

How the test works

The dead pixel test displays full-screen solid colors in sequence: Black (#000000), White (#FFFFFF), Red (#FF0000), Green (#00FF00), and Blue (#0000FF). Each color fills the entire viewport, making it easy to spot pixels that don't match the background.

Dead pixels appear as permanently black dots (all three sub-pixels — red, green, blue — have failed). Stuck pixels appear as permanently lit colored dots (one or more sub-pixels stuck in the "on" state). Cycling through colors helps reveal both types because defective pixels stand out against uniform backgrounds.

The test is purely visual — the browser renders the colors, but you are responsible for inspecting the screen. The test cannot automatically detect pixel failures because it has no way to verify what the physical display is showing (the browser sends pixel data to the display, but cannot read it back).

What the test detects

Nothing automatically — the test provides a systematic way for you to visually inspect your display. By showing 5 carefully chosen solid colors, it covers the most common dead/stuck pixel scenarios: black catches dead pixels, white catches dark defects, and RGB colors catch stuck sub-pixels.

What the test cannot detect

The test cannot prove whether a pixel failure is permanent without hardware-level inspection. Some stuck pixels can be repaired through software tools. The test also cannot detect subtle defects like slight color non-uniformity, backlight bleeding (though this is visible on the Black screen), or defects only visible at extreme viewing angles.

Why you must inspect the screen yourself

The browser sends pixel data to the display hardware, but it has no API to read back what the display is actually showing. A pixel could be commanded to show red but physically display black (dead) or a different color (stuck). Only your eyes can detect this mismatch.

How the test works

The refresh rate test uses requestAnimationFrame() to count display frame callbacks over a 3-second measurement window. Each time the browser calls the animation frame callback, the test increments a frame counter.

After 3 seconds, the test calculates: FPS = frameCount / elapsedSeconds. It then rounds to the nearest common refresh rate from the list: 30, 60, 90, 120, 144, 165, 240 Hz. The raw measurement is displayed alongside the detected rate.

The test counts frame callbacks, not display panel updates. requestAnimationFrame is synchronized with the display's vsync signal, so the callback rate typically matches the display's refresh rate — but only when the browser tab is active, visible, and not throttled.

What the test detects

The display's current refresh rate as experienced by the browser. This reflects the rate your display is actually running at, which may differ from the panel's maximum specification (many phones default to 60Hz to save battery and only switch to 120Hz when scrolling or in supported apps).

What the test cannot detect

The test does not directly read the panel's factory specification. It measures the browser's rendering frame rate, which is capped by the display's actual refresh rate. If your 120Hz phone is set to 60Hz in display settings, the test reports 60Hz — that's what the display is currently running at.

Browser throttling limitations

When a browser tab is in the background or the device is in power-saving mode, the browser may throttle requestAnimationFrame to a lower rate (e.g., 1 Hz or even pause entirely). The test must be run with the tab in focus for accurate results.

How the test works

The FPS test renders an animated canvas scene with 15 colored balls bouncing around the screen. Each frame, the test calculates the time delta between the current and previous frame using performance.now(). The FPS is computed as 1000 / avgDelta, averaged over the last 60 frames.

The test displays three metrics: current FPS (updated every frame), average FPS (over the entire test), and minimum FPS (worst-case frame drop). The test runs for 6 seconds by default, or you can stop it early.

The scene uses CanvasRenderingContext2D with arc, fill, and stroke operations — moderately complex 2D rendering that stresses the GPU more than simple rectangles but less than full 3D scenes.

What the test detects

Your device's ability to render frames in the browser's 2D canvas context. Average FPS of 60+ indicates the GPU can keep up with the display's refresh rate. Values below 30 indicate GPU limitations, thermal throttling, or excessive background load.

Critical limitation: Browser FPS ≠ Game FPS

Browser FPS is not necessarily the same as FPS inside a native game or application. Native games use GPU APIs like Vulkan, Metal, or DirectX directly, which have lower overhead than the browser's Canvas 2D API. A device that achieves 60 FPS in this test may achieve different frame rates in native games. Conversely, a device that shows 40 FPS here may run native games at higher frame rates because the games use more efficient rendering paths.

How the test works

The gyroscope test uses the Device Orientation API (deviceorientation event) to read three rotation values from your device's motion sensors:

• Alpha (0-360°): Rotation around the Z-axis, like a compass heading
• Beta (-180 to 180°): Rotation around the X-axis, front-to-back tilt
• Gamma (-90 to 90°): Rotation around the Y-axis, left-to-right tilt

The test renders a ball on a canvas that moves based on the beta and gamma values. A target ring appears at the center. You must tilt your device to roll the ball into the target and hold it there for 1.5 seconds to pass.

iOS permission requirement

On iOS 13+, Apple requires explicit permission before websites can access motion sensors. The test calls DeviceOrientationEvent.requestPermission() when this function is available. If permission is granted, the deviceorientation event fires and the test begins. On Android and desktop browsers, no permission is required.

What the test cannot detect

Desktop computers typically lack accelerometers and gyroscopes — the test will show zeros and the ball won't move. This is expected behavior, not a failure. The test also cannot measure sensor accuracy, calibration quality, or drift. Minor noise in sensor values is normal.

How the test works

The vibration test uses the Vibration API (navigator.vibrate()) to trigger your device's haptic motor. The test calls navigator.vibrate(500), which instructs the device to vibrate for 500 milliseconds.

If your device vibrates, the haptic motor responds to software commands and is functional. If it doesn't vibrate, the API may not be supported by your browser/device, or the motor may be defective.

Browser and device support

The Vibration API is supported on most Android browsers (Chrome, Firefox) but is not supported on iOS Safari or most desktop browsers. If the test shows "Vibration API not supported", it doesn't mean the motor is broken — it means the browser doesn't expose the vibration API.

What the test cannot detect

The test cannot measure vibration strength, pattern accuracy, or motor wear. A motor that vibrates weakly may still pass this test. The test only confirms that the motor responds to a basic vibrate command.

How the test works

The keyboard test listens for keydown and keyup events on the document. When a key is pressed, the test reads the event.code property (which identifies the physical key, regardless of keyboard layout) and highlights the corresponding key on a visual keyboard layout.

The test maintains a set of all pressed keys and updates the visual keyboard in real time. Each key changes color when pressed and returns to its default state when released.

What the test detects

Whether each physical key on your keyboard generates a keydown/keyup event. This confirms the key switch is electrically functional at the OS level.

What the test cannot detect

The test cannot measure key actuation force, travel distance, or mechanical wear. A key that feels mushy or inconsistent may still register events. The test also cannot detect key chattering (a single press generating multiple events) unless it happens during the test window.

How the test works

The internet speed test measures latency (round-trip time) and jitter (latency variation). It sends 5 HEAD requests to httpbin.org at 200ms intervals, measuring the time each request takes to complete.

Latency is calculated as the average of the 5 round-trip times. Jitter is calculated as the average of the absolute differences between consecutive latency measurements. Both values are reported in milliseconds.

What the test detects

How responsive your internet connection is (latency) and how consistent it is (jitter). Under 50ms latency is excellent for real-time applications. High jitter (over 50ms) causes choppy video calls and lag spikes even when average latency is acceptable.

Critical distinction: Latency ≠ Bandwidth

This test does not measure download/upload speed in Mbps. Latency measures response time (how fast a packet round-trips). Bandwidth measures throughput (how much data transfers per second). Both are important but different metrics. Use Ookla Speedtest or Fast.com for bandwidth testing.

Why results vary

Network conditions change constantly based on server load, Wi-Fi signal strength, network congestion, and the number of devices sharing your connection. Run multiple tests at different times for a more accurate picture of your typical performance. The test server (httpbin.org) is at a fixed location — server distance affects latency measurements.

How the test works

The headphone test is an extended version of the speaker test. It includes three sub-tests: stereo channel test (left/right panning at 440 Hz), frequency sweep (200 Hz to 8000 Hz), and phase test (both channels in phase vs out of phase).

The stereo test uses the same StereoPannerNode as the speaker test. The frequency sweep uses a continuous oscillator that sweeps through the audible range. The phase test plays the same tone on both channels with a 180° phase difference to test stereo separation.

What the test detects

Whether both earpieces produce sound, stereo separation works, and the frequency response covers the audible range. If you hear audio from both sides during the stereo test, both drivers are functional.

What the test cannot detect

The test cannot measure driver quality, impedance matching, frequency response flatness, or maximum volume. A headphone that passes this test may still sound poor at high frequencies or have uneven frequency response. Professional audio measurement requires calibrated equipment.