joygoLive WCP
WCP · Web Capability Probe

What your device actually gives the web.

Every capability is invoked in your own browser and the result recorded. It is neither a support table nor a feature-detection list, because declared support and actual execution frequently differ.

Run it on your device What we found

Submit the result and you get a report back. Where your device sits in the sample (upper, middle, or lower) and which capabilities opened, needed permission, or were closed on it.

A service by joygoLive, built here and operated here. 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 response headers, recorded 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 enumerationEach item is invoked. A result is a return value or a thrown error, never a capability string.
Five states, not twoOpen · permission required · broken · absent · unmeasured. Collapsing these to yes/no loses the case that matters most.
A control groupThe same page is served twice, once with cross-origin isolation headers, to separate device limits from server configuration.
Nothing identifying is asked forNo 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 absentNo 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 blocked items are not gapsDeliberate 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 cosmeticSafari, Chrome, and Edge on the same iPhone returned byte-identical measurements. All three are WebKit.
In-app browsers close capabilitiesthat 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 deviceThe most open environment in this sample is not the fastest one.
Method

Methodology

A figure is only as reliable as its methodology. This is the methodology, and it does not change when the figures do.

Four groups

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 measured

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

A ledger independent of sample size
—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 layers where a capability fails

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

1 · No hardwareThe part is not in the device. Nothing above can fix it.
2 · OS does not expose itPresent in hardware, absent from the platform API.
3 · Browser policyExposed by the OS, withheld by policy. Usually fingerprinting.
4 · Host app restricts itAn in-app WebView, narrower than the browser it is built on.
5 · Server response headersThe site's own response headers, blocking what the device could expose.

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 does not claim

A support list inflates the moment untested items are counted. Below is what the figures above do not claim.

The sample is smallMost of the sample is ours. Treat the numbers as a direction, not a population statistic.
A web app cannot see outside itselfRunning processes, installed apps, battery history, storage breakdown: all invisible from a page. Anything claiming otherwise from a browser is an estimate.
The native comparison is documented, not measuredNo native app was built to compare against, so that classification is documented rather than measured, and labeled as such.
Network readings are excluded from every scoreThey measure the line at that moment, not the device. A phone on good Wi-Fi would otherwise outrank a faster one.
Detected is not executedWhere a capability can only be checked for existence, never invoked, it is recorded as detected and labeled that way.
Numbers move between runsHeat, 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.