DeviceOK
SearchDevice checks
Home / Checks / Browser Permission Checkup
People whose hardware works but a website cannot access it

Browser Permission Checkup

Check the browser permissions and capabilities that commonly block cameras, microphones, location, notifications, fullscreen, and screen sharing.

Inspection principle

Permission failures exist at several layers: browser site permission, operating-system privacy controls, organization policy and device availability. Changing drivers rarely fixes a permission denial.

Progress0 of 8 checks recorded
Run next live test ↗

Run the browser-visible checks, then record the physical/native checks below. Progress stays in this browser unless you deliberately copy the fragment share link.

Live evidence

Browser-visible checks

1
Camera and microphone permissionsCheck whether common browser permissions such as camera, microphone, location, and notifications are granted, denied, or still waiting for a decision.
Run test ↗
2
Screen sharingVerify that your browser can open the screen/window/tab sharing picker and start a local capture stream.
Run test ↗
3
Location accessCheck whether your browser can obtain a location fix and see the reported accuracy without sending it to DeviceOK.
Run test ↗
4
NotificationsCheck whether browser notifications are supported and whether the site permission is granted or blocked.
Run test ↗
5
Fullscreen capabilityVerify whether the browser can enter fullscreen mode from a user action.
Run test ↗
Outside the browser

Physical & native checks

These close the blind spots a website cannot inspect.

1
Site permission state

Open the browser's site permissions for DeviceOK and the affected site; confirm camera/mic/location settings are not explicitly blocked.

Why it matters: Per-site blocks override a device that otherwise works.
2
Operating-system privacy

Check the OS privacy controls for the browser/app when the browser cannot obtain access.

Why it matters: The OS can deny access before the website receives a device stream.
3
Managed policy

If the device is work/school managed, identify whether a policy controls the permission.

Why it matters: Managed restrictions should be handled by the administrator, not bypassed.
Stop / escalate

Conditions that deserve caution

  • The device is managed and policy changes are not authorized.
  • The permission request concerns a device/data source you do not intend to expose.
Decision rule

How to use the evidence

A permission denial is configuration/policy evidence, not hardware-failure evidence. Resolve the highest blocking permission layer first.

0 passed0 need attention0 skipped