Phone Check Guide
A reference for Phone Check, the DeskTest.net tool that tests a phone or tablet in the browser with no app to install. It runs the six checks a browser can honestly answer, rolls them into one readiness score, and - just as importantly - is upfront about the things a web page simply cannot see. This guide explains each check, what the score means, and where the honest limits are.
What Phone Check does
Phone Check is a short, guided walkthrough for a phone or tablet, run entirely in the browser. Open it on the device you want to test and tap Start phone check; it steps through the touchscreen, motion sensors, cameras, microphone and speaker, vibration, and network, one tile at a time. Each check that needs the camera, microphone, or motion sensors asks the browser's own permission prompt first - nothing turns on without your tap. At the end you get a single readiness score, a per-check breakdown, and a plain-language list of what could not be checked. It is a fast "is this device working?" snapshot - useful when buying or selling a used phone, or handing a device to a new employee - not a forensic diagnostic.
edge.desktest.net - DeskTest.net's own server - to confirm you can reach the internet and measure round-trip time. The camera and microphone previews stay on the device; nothing is recorded or uploaded.The six checks
Each check is graded Works (green), Attention (amber, needs a look), Problem (red, likely a real fault), or N/A (gray, not applicable on this device or skipped). Because several checks rely on what you can see, feel, or hear, some results are your confirmation rather than a machine measurement - the tool says so wherever that is the case.
1. Touchscreen
Reads navigator.maxTouchPoints and listens with Pointer Events (falling back to Touch Events on older Safari) while you drag across a pad and place two fingers down. It reports the most fingers tracked at once - so it can confirm multi-touch - and lights up a grid as you cover the pad. If a patch never lights up, that hints at an unresponsive area. This is a quick responsiveness check, not a calibrated dead-zone scan, so treat a dark patch as a prompt to look closer, not a verdict. A non-touch device (a desktop) is reported as N/A rather than a failure.
2. Motion sensors
Listens to DeviceMotionEvent (accelerometer and, via rotationRate, gyroscope) and DeviceOrientationEvent (tilt and compass heading) while you tilt and rotate the device. On iOS these require a permission tap, so the check shows an Enable motion sensors button that calls the iOS requestPermission() API before it can listen. It grades Works when both the accelerometer and gyroscope respond, and Attention if only one does. The magnetometer/compass is frequently unavailable to the browser - especially on iOS - so a missing heading is reported honestly and never counted as a fault.
3. Cameras
Requests the rear camera with getUserMedia({video:{facingMode:'environment'}}), shows a live preview, and lets you flip to the front lens. After permission it counts the video inputs the browser reports. Works means a preview appeared; two cameras or two facings previewed indicates front and rear are both present. The browser exposes a camera count and a front/rear hint only - it cannot guarantee which physical lens is which without device labels, and it cannot judge image quality, focus, or the flash. A blocked permission is a Problem with a fix; the preview stream is stopped the moment the check ends.
4. Microphone + speaker
Two parts in one tile. For the microphone, getUserMedia({audio:true}) feeds a Web Audio analyzer and a live level bar - speak or tap the device and the bar moves. For the speaker, a 440 Hz sine tone is generated locally (an OscillatorNode with a soft envelope) and you confirm whether you heard it. Works needs both: a real input level and your "I heard it". The speaker result is explicitly your confirmation - a browser cannot listen to its own speaker - so the tool never claims to have measured audio output. The mic stream and audio context are torn down when the check finishes.
5. Vibration
Calls navigator.vibrate() and asks whether you felt it. This is Android territory: iOS Safari has never supported the Vibration API, so on an iPhone or iPad it is reported N/A with a note that this says nothing about the physical motor. Critically, navigator.vibrate() returning true does not prove the motor fired, so the result rests on your answer, not the API's return value.
6. Network
Checks navigator.onLine, then makes one small request to edge.desktest.net and times the round trip, reporting reachability, latency, and whether egress is IPv4 or IPv6. Reaching the internet quickly is Works; a slow round trip is Attention; no reply is a Problem - often a captive portal, VPN, or content blocker. This measures reachability and latency, not download speed.
What a browser cannot check
This is the most important part of Phone Check, and it is shown on every result. A web page has no access to several things a used-phone buyer cares about, so the tool states them plainly instead of implying a pass:
- Battery health. A browser can only ever read charge level, and only where the Battery API exists (Chromium on Android; never on iOS). True battery health, capacity, and wear are not exposed - check the phone's own settings or a shop tool.
- IMEI, carrier lock, and blacklist / lost-or-stolen status. None of these reach a web page. Read the IMEI from the dialer (
*#06#) and check it against the carrier or a blacklist service separately. - Storage health, capacity, and wear. The real storage size and flash wear are invisible to the browser; use the device's Settings > Storage.
- Physical condition. Cracks, water damage, and case wear are visual - this test only exercises the sensors and radios the browser can reach.
Because these are unanswerable in a browser, they never appear as a green result. Trust depends on that line never blurring.
How the readiness score works
Each gradable check is scored Works, Attention, or Problem, and each carries a weight, so the parts that matter most to daily use count for more - the touchscreen weighs the most, then the cameras and audio, while vibration weighs the least. A Works counts in full, an Attention counts a little over half, and a Problem counts zero. Checks that come back N/A or are skipped are left out of the maths entirely, so a device without a gyroscope is not penalised for hardware it never had. The weighted result is the number in the ring, labeled Ready. Treat it as a quick indicator, not a precise grade: a high score reads as ready, the middle range means a few things need a look, and a low score - or any hard Problem - means something is likely faulty. The ring never speaks to the items in the "cannot be checked" list.
iOS and Android differences
| Capability | Android (Chromium) | iOS (Safari) |
|---|---|---|
| Motion sensors | Usually available without a prompt | Behind a permission tap (requestPermission()), handled by the tool |
| Compass / magnetometer | Sometimes exposed | Often unavailable to the browser |
| Vibration | Supported | Not supported at all (reported N/A) |
| Battery charge level | Battery API present | No Battery API |
| Camera / microphone | getUserMedia with permission | getUserMedia with permission |
Every one of these gaps is labeled in the result rather than hidden, so an iPhone is never marked down for a limit that is Apple's, not the device's.
Reading and sharing the report
Every check is a tile you can expand for the exact readings and, when something needs attention, a plain-language "What to do". Below the dashboard are three buttons:
- Copy report copies a plain-text version of the whole run - the score, every check with its status and readings, and the honest "cannot be checked" list - ready to paste into a listing, ticket, or email.
- Send to your IT opens a pre-filled email containing that same report.
- Run again clears the dashboard and starts over.
A View report toggle shows the exact text the two buttons use. The report includes the browser's user agent and the page origin, but no photos, audio, files, or personal data.
White-label for IT teams
Two optional URL parameters let a team hand staff a branded, pre-addressed version - no build step, just a link:
?org=<name>adds a banner naming the organization and stamps that name onto the report.?support=<email>points "Send to your IT" at that address, so the pre-filled email is already addressed to your help desk, and the banner shows where the report goes.
For example, https://desktest.net/phone-check/?org=Acme%20Property&[email protected] opens Phone Check branded for Acme Property with the report pre-addressed to the help desk. The organization name is length-capped and only ever displayed; the parameters are read from the URL and never leave the browser except in the email you choose to send.
Related tools
Phone Check is a fast summary of tools that each go deeper. Open the one a tile points you to:
- Touch Test - a full multi-touch and dead-zone capture.
- Webcam Test - detailed camera enumeration and preview.
- Microphone Test - input level, recording, and playback.
- Speaker Test - per-channel tone and stereo checks.
- Network Test - reachability, DNS, WebSocket, latency, and jitter in detail.
- System Info - everything the browser reveals about the device.
- Full Workstation Checkup - the desktop-focused sibling of this flow.
See also About DeskTest.net and the DeskTest.net home.