Skip to main content
Documentation menu
On this page

Mobile

Mobile Device Test

A thirteen-item capability scan of your phone — touch, sensors, screen, camera, microphone, audio, network, battery, haptics and wake lock — in one page.

  • Available — Live on this site right now.
  • Browser Tool — Runs in the browser you are reading this in.
  • No Install — Nothing to download, no extension, no account.
  • Requires Permission — Asks your browser for access before it can run.
  • Mobile — Built for phone and tablet hardware.

Live tool: /mobile-device-test/

This page explains the tool. The tool itself is one click away and needs no sign-in.

Open Mobile Device Test

What is this tool?

The Mobile Device Test is the overview page: instead of testing one thing deeply it asks your browser what it can do, thirteen capabilities at a time, and reports each as supported, permission-required or unavailable. It is the right first stop when you do not yet know what is wrong.

Each panel is backed by a specific API. Touch uses navigator.maxTouchPoints and live pointer events; orientation and motion use DeviceOrientationEvent and DeviceMotionEvent; camera, microphone and their level meter use getUserMedia; audio uses the Web Audio API; network uses navigator.onLine and the Network Information API; battery uses navigator.getBattery; haptics use navigator.vibrate; and Prevent Sleep uses the Screen Wake Lock API.

Because it is a capability scan rather than a hardware probe, it is honest by construction: an item reads unavailable when the browser does not expose it, which is a statement about the browser, not a verdict on your phone. The page's own “Why Some Features Show Not Supported” section makes the same distinction.

How to use it

  1. Read the automatic panels firstDevice information, screen and display, touch support, network and battery populate on load without any permission. Device type, browser and OS come from the user agent; screen width, viewport width and device pixel ratio come from the screen and window objects.
  2. Run Device Check for a summaryThe single Run Device Check button walks the thirteen capability items and produces supported, permission and unavailable counts. Use it as your triage list, then drill into the individual buttons for the ones that matter.
  3. Grant permission for the sensor testsTest Orientation and Test Motion need DeviceOrientationEvent and DeviceMotionEvent. On iPhone and iPad these require an explicit tap and a permission grant, which is why the buttons exist rather than the panels just filling themselves in.
  4. Test camera, microphone and audio individuallyTest Camera opens a preview stream, Test Microphone opens an input level meter, and Play Test Sound synthesises a tone through the Web Audio API. Each one asks the browser for permission at the moment you press it, and each releases the device when you stop.
  5. Try the system capabilitiesVibrate fires a short haptic pulse, Prevent Sleep requests a screen wake lock, Test Location asks for geolocation and Run Connection Test times a single request. These are the four items that visibly do something rather than report something.
  6. Move on to a dedicated tool for detailThis page proves a capability exists. When it says touch works but something still feels wrong, the deep tests — touch screen, gyroscope, compass, vibration, microphone, speaker — are where the actual diagnosis happens.

What the results mean

Supported, Permission and Unavailable

Three states across thirteen items. Supported means the API exists and answered. Permission means it exists but needs your consent before it will produce data — camera, microphone, motion and geolocation are all in this group by design. Unavailable means the browser does not expose it at all.

Device information

Device type, browser, OS, platform, language, timezone and cookie state, derived from the user agent and navigator. The exact model deliberately reads as not available, because browsers do not expose it — the page has its own FAQ saying so.

Screen and display

Screen width and height, available area, viewport width and height, device pixel ratio and colour depth. Screen and viewport differ because the viewport excludes browser chrome, which is why a 1080-wide phone shows a much smaller viewport in CSS pixels.

Touch support and multi-touch

Whether touch exists and the maximum contact count the browser advertises through navigator.maxTouchPoints, plus a live count while you touch the panel. The multi-touch item counts as supported only when that maximum is above one.

Battery

Level percentage, charging state and, where the browser provides them, estimated charging and discharging times. Many browsers have removed the Battery Status API for privacy reasons, so unavailable here is common and expected on desktop and on iOS.

Network telemetry

Online state from navigator.onLine, plus effective type, downlink estimate, round-trip estimate and data-saver flag when the Network Information API exists. Those numbers are the browser's own coarse estimates, not a speed test.

Connection test result

One round-trip figure in milliseconds. It is produced by timing a single HEAD request to this site's own /favicon.svg with caching disabled — a reachability and responsiveness check, not a bandwidth measurement.

What it can detect

  • Which of thirteen browser capabilities your device and browser actually expose, with permission-gated items separated from genuinely missing ones
  • Whether touch and multi-touch are reported at all, and the contact ceiling the browser advertises
  • Whether motion and orientation sensors are present, and whether they need an explicit permission grant on this device
  • Whether camera, microphone and audio output can be opened at all in this browser
  • Whether the browser exposes battery status and network telemetry, both of which are commonly withheld for privacy
  • Whether haptics, screen wake lock, geolocation and fullscreen are available
  • Screen versus viewport dimensions and device pixel ratio, which is the fastest way to explain why a layout looks different than expected

Limits worth knowing

A browser can only report what the platform gives it. These are the honest boundaries of this page, so a result is never read as more than it is.

  • This is the one tool on the site that makes a network request, which is why it does not carry the client-side badge. Pressing Run Connection Test performs a single HEAD request to /favicon.svg on this same site so the round trip can be timed. No test results, no device information and no telemetry travel with it, and nothing is uploaded anywhere — everything else on the page is computed locally.
  • It cannot read your device model, serial number, IMEI or firmware version. Browsers do not expose them, and the page's own FAQ answers “Why does Device Model say not available in browser?” with exactly that.
  • It cannot report CPU temperature, battery health, cycle count or charging wattage. Those live below the browser entirely, and no web page on any device can reach them.
  • It cannot tell you whether a phone is refurbished, counterfeit or has been repaired. The page has an explicit FAQ on this, and the honest answer is no — a capability scan describes what the browser can do, not the provenance of the hardware.
  • It cannot confirm that vibration physically happened, that the camera image is in focus, or that sound left the speaker. It can only confirm that the API accepted the request; your senses supply the rest, which is what the dedicated vibration, speaker and microphone tools are built around.
  • Camera and microphone streams are previewed and metered locally and never recorded or transmitted — the page's own FAQ on uploading answers this directly. Streams are released when you stop the test.
  • Network telemetry values are browser estimates, and the Network Information API is missing in Safari and Firefox altogether. Unavailable there is a browser policy decision, not a fault.

Tips

  • Start here, then go deep. Use the capability summary to decide which specialised test to open next rather than guessing which subsystem is at fault.
  • Compare the same phone in two browsers before concluding a sensor is broken. Motion, battery and network reporting differ substantially between Safari, Chrome and Firefox, and a difference between browsers means the hardware is fine.
  • Note that permission-gated items are not failures. Camera, microphone, motion and location are supposed to require your consent — a page that read them without asking would be the problem.

Troubleshooting

Motion sensors say permission required and nothing happens.

On iPhone and iPad, DeviceMotionEvent needs an explicit request triggered by a tap, and it must be served over HTTPS. Press Test Motion directly, accept the prompt, and if you dismissed it earlier clear the site's settings in Safari and reload.

Battery shows unavailable.

Expected on Safari, on iOS and in Firefox — the Battery Status API was removed for privacy. Chrome on Android is where it usually reports. This is a browser policy, not a battery fault.

Device model says not available in browser.

Correct, and unavoidable. Browsers expose a user-agent string that names the OS and browser, not the handset. Nothing this page could do would recover the model name.

The connection test shows a very small number.

It should. The request goes to this site's own favicon, so on a warm connection the round trip is a few milliseconds. It is a reachability and responsiveness check, not a bandwidth or ping-to-the-internet measurement.

Some panels stay empty in private browsing.

Private and incognito modes restrict storage and several device APIs, so capability results can differ. Re-run in a normal window before drawing any conclusion about the device.

Ready to run it?

A thirteen-item capability scan of your phone — touch, sensors, screen, camera, microphone, audio, network, battery, haptics and wake lock — in one page. Nothing to install, and it opens in this browser.