WCP · Web Capability Probe

What your device actually gives the web.

Every capability is invoked in your own browser and the result recorded. Not a support table, not a feature-detection list, because a browser answering "yes" and a browser doing the thing are two different answers.

Run it on your device What we found

Send the result and you get one back. Where your device sits in the sample — upper, middle, or lower — and which capabilities opened, needed permission, or were closed on it.

A measurement tool by joygoLive. Open the link on the device you want measured.

Premise

Declared support, working support

A capability table answers "is it in the spec". It cannot answer "does it work on this phone, in this browser, right now". Between the two sit the OS, the browser's own policy, the app hosting the WebView, and the response headers of the site itself.

Declaration present, execution failedThe API answers, the call fails. More dangerous than absence: code takes that path believing it works.

Same hardware, different answerOne device, four browsers, four results. The variable is not the silicon.

Our own headers, counted as absenceSharedArrayBuffer read as closed until COOP and COEP were added. The device was never the limit.

Scope

What it measures

Sensors, GPU and NPU, codecs, radios, storage, permissions, network, security context, and identity. Numbers where a number exists: GPU matrix multiply in GFLOPS, buffer ceilings in MB, refresh rate in Hz.

Execution, not enumeration. Each item is invoked. A result is a return value or a thrown error, never a capability string.
Five states, not two. Open · permission required · broken · absent · unmeasured. Collapsing these to yes/no loses the case that matters most.
A control group. The same page is served twice, once with cross-origin isolation headers, to separate device limits from server configuration.
Nothing identifying is asked for. No account, no contact details. Device model, browser, and measurements only.

Current sample

What the measurements say

The sample is small and stated as such. The figures below are read live from the tool, so they are whatever the measurements currently say.

Wi-Fi is not restricted on the web. It is absent. No scan, no signal strength, no channel, no security mode. The one related reading is whether the connection is Wi-Fi or cellular, and that answers only on Android Blink. Every iOS environment in the sample returns nothing.
Most closed doors are not gaps. Deliberate refusals against fingerprinting outnumber genuine native gaps in this sample. Counting every unavailable item as a gap inflates the number.
On iOS the browser choice is cosmetic. Safari, Chrome, and Edge on the same iPhone returned byte-identical measurements. All three are WebKit.
In-app browsers close capabilities that the same phone opens in a standalone browser. A link opened from a messenger is a different device, as far as the web can tell.
Open and fast are not the same device. The most open environment in this sample is not the fastest one.

Method

How it is kept

A number is only worth what the method behind it is worth. This is the method, and it does not change when the numbers do.

Five states, not two

Open everywhere, permission everywhere, decided by the environment, closed everywhere. The third group is the interesting one: the hardware is not what decides.

Nine groups of checks

Radios, compute, motion, device, I/O, storage, camera, audio, location. Each item is invoked, and a result is a return value or a thrown error.

Engine builds actually walked

The UA engine token is frozen and useless (537.36, 605.1.15). What decides is the Chrome build or the OS build, so that is what gets recorded.

A ledger that does not grow with the sample

—bands kept

History is stored per month × engine build × OS, not per device, so ten samples and ten thousand produce the same number of rows. Kept for five years by default.

Diagnosis

Five places a capability dies

"It does not work" is one sentence covering five different causes. Only the first is about the device.

1No siliconThe part is not in the device. Nothing above can fix it.

2OS does not expose itPresent in hardware, absent from the platform API.

3Browser refusesExposed by the OS, withheld by policy. Usually fingerprinting.

4Host app restricts itAn in-app WebView, narrower than the browser it is built on.

5Our own headersThe site's own response, closing what the device was ready to give.

Wi-Fi belongs to none of the five. There is no Wi-Fi API in the web platform to refuse in the first place, so the question of which layer blocks it never arises. That is a different answer from "closed", and the tool reports it as such.

Limits

What this will not claim

The sample is small. Most of the sample is ours. Treat the numbers as a direction, not a population statistic.
A web app cannot see outside itself. Running processes, installed apps, battery history, storage breakdown: all invisible from a page. Anything claiming otherwise from a browser is guessing.
The native comparison is knowledge, not measurement. No native app was built to compare against, so that classification is documented rather than measured, and labelled as such.
Network readings are excluded from every score. They measure the line at that moment, not the device. A phone on good Wi-Fi would otherwise outrank a faster one.
Detected is not executed. Where a capability can only be checked for existence, never invoked, it is recorded as detected and labelled that way.
Numbers move between runs. Heat, low-power mode, other load, charging state. A single reading is not a property of the device.

Measure your own device Takes about a minute. You get your tier and a full breakdown back.