How Browser Permissions Work

Calling a browser API is one thing. Getting permission to use it is another. Before any capability that touches hardware or personal data can run, the browser acts as a gatekeeper -- and it has a fairly nuanced set of rules for when and how to grant access.

Not All APIs Need Permission

Some capabilities are completely open. Playing audio through the speakers, for example, requires no permission. Reading the current time, checking the viewport size, accessing the DOM -- all free. These have no privacy risk and no real-world cost.

Others sit in a middle tier. They expose data about the user or the device, so the browser requires the user to explicitly say yes. Camera, microphone, geolocation, Bluetooth, NFC, notifications -- all of these go through the permission system.

A smaller set carries actual financial or operational cost. Sending an SMS or initiating a call from the browser falls into this category. The bar for those is correspondingly higher.

How Permissions Are Granted

The most common mechanism is the permission dialog: a browser-level popup asking "Allow this site to access your location?" or "Allow camera access?" The developer's code triggers the request, but the browser controls the dialog. You cannot style it, fake it, or skip it.

A less visible mechanism is the user engagement requirement, which Chrome uses for certain background APIs. Background Sync is a good example. When you request a background sync operation, Chrome does not show a dialog at all. Instead, it silently checks whether the user is actively engaging with your app on a regular basis. If engagement is high enough, the permission is granted automatically. If not, it is denied. You cannot influence that algorithm -- it runs on Chrome's side.

HTTPS Is Required

Most sensitive capabilities require HTTPS. On Chromium-based browsers this is enforced strictly. Geolocation, camera, microphone, Bluetooth, Web Push -- none of these will work over plain HTTP. Safari is more lenient on this for some APIs, but HTTPS is the correct assumption to work from.

This is not just a capability restriction. Running over HTTPS is the baseline expectation for any production web app today.

User Interaction Before Asking

You cannot request a permission-triggering API the moment a page loads. If you call navigator.geolocation.getCurrentPosition() immediately on page load, the browser will either block it or deny it automatically. The user has to interact with the page first -- click a button, tap a control -- before a permission dialog can appear.

This is a deliberate UX fix. Before this rule existed, sites would fire permission requests on load before the user had any context for why the site needed the capability. Denial rates were high. Now, permissions are requested at the moment of action: the user clicks "Find stores near me," and only then does the geolocation request happen.

Permissions Are Per Origin

When a user grants permission for a capability, that grant applies to the entire origin -- the full domain. If you are granted camera access on app.example.com, every page and route within that origin has access. You cannot grant permission to one subfolder and deny it to another, or scope it to a specific manifest or service worker.

If your app lives at a subdomain (dashboard.example.com) and you need the same permissions as the main domain (example.com), those are treated as separate origins with separate permission grants.

When a User Says No

If a user denies a permission, your JavaScript cannot ask again. Any subsequent call to request that permission is automatically denied without showing a dialog. The browser respects the user's decision and does not let you override it.

The only path forward is to show the user a message explaining what to do, then let them take action manually. They need to go into the browser's site settings and re-enable the permission themselves. Most browsers surface this in the address bar (a small icon indicating a blocked permission) or in the site info panel.

How Long a Permission Lasts

Permission duration varies by capability and by browser. There is no single rule:

Capability	Typical duration
Camera and microphone	Per session
Geolocation	Per usage (asked each time)
Notifications (Web Push)	Until explicitly revoked
Bluetooth	Per session or per connection

You cannot control this duration from code. It is the browser's decision, and it varies. The safest approach is to always handle the case where the permission is no longer granted -- check before calling, and degrade gracefully if access is denied.