Prompting users for permission, thoughtfully
Web permission prompts are the primary safeguard between powerful APIs and user privacy. They exist to confirm that a user actually intends to grant a specific capability—such as camera, microphone, geolocation, notifications, or MIDI access—to a specific site. But a prompt is only protective when it is meaningful. Chrome usage statistics and user research consistently show that prompts shown without context are mostly ignored or denied, and unnecessary denials can lock users out of features they might otherwise want.
Ask in context, not on arrival
The single most common mistake is requesting permission on page load. That is the web equivalent of asking a customer for personal details the moment they walk through the door. Users arriving at an unfamiliar site need time to understand what it offers before they are willing to grant access to sensitive capabilities. Asking immediately, often alongside cookie banners and newsletter popups, is jarring and counterproductive.
The data backs this up. In Chrome telemetry, 77% of permission prompts on desktop are shown without any signal of user intent, and only 12% of those prompts are allowed. When a prompt follows a user interaction, the allow rate rises to 30%. The implication is straightforward: only request permission after the user has actively engaged with the page.
Make the reasoning visible
Permission decisions are, in practice, privacy decisions. Users evaluate a request not just on what it accesses, but on why it is being accessed and what they get in return. Research based on the contextual integrity framework shows that users are significantly more likely to allow access when they understand the usage context and perceive a clear benefit.
Many users will deliberately explore a site before committing to a permission decision, and some may allow one-time access first to test the value. Build your flow to accommodate that behavior. Avoid requesting capabilities that users are unlikely to see as necessary, and time requests so the benefit is apparent at the moment of the prompt.
Offer an alternative path
Not every user will want to grant access even when the request is well-timed. Geolocation on a desktop device may be inaccurate, clipboard access may feel unnecessary when keyboard shortcuts already work, and some users simply prefer not to grant notification access. For every permission-gated feature, provide an alternative that achieves the same outcome.
For geolocation, offer a text field for entering a zip code or address. For clipboard operations, ensure users can still copy and paste via keyboard shortcuts or the context menu. For notifications, present an email option alongside push. These alternatives also serve a second purpose: they help explain, implicitly, what the permission is for. A user who sees both a “Use my location” button and a zip code field understands the tradeoff immediately.
Prevent blocked states before they happen
Once a user permanently denies a permission, browsers honor that decision. Re-prompting would enable abusive sites to harass users, so recovery is intentionally difficult. The practical consequence is that you should avoid triggering a browser prompt in situations where denial is likely. A common safeguard is a pre-prompt: a lightweight UI element explaining what is about to happen and why, which only triggers the actual browser permission dialog when the user responds affirmatively.
Good moments to ask include: after a user clicks a button labeled Use my location next to a form field, after a user subscribes to updates and confirms a dialog offering email or notification delivery, or after a user arrives at an intake page for a video call and confirms via pre-prompt that they want to be seen and heard.
Audit third-party code
Permission prompts can originate from sources outside your control. Third-party scripts and libraries may request permissions on their own, and if they do so poorly, your users blame you. Review the documentation of any third-party code you integrate to understand what permissions it may request and when.
Permissions request patterns in code
The way an API requests permission varies. Some APIs trigger the browser prompt automatically on first use. The Geolocation API, for example, asks when you call navigator.geolocation.getCurrentPosition():
try {
navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
console.error(error);
}
Other APIs require an explicit request before any sensitive method can be called. For example, Notification.requestPermission() for notifications, or DeviceOrientationEvent.requestPermission() for the Device Orientation Events API:
const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
/* Use the API. */
}
Behavior is not consistent across browsers. Chrome, for instance, automatically grants device orientation access, while Safari presents a prompt.
Checking and managing permission state
Before working with a permission-gated API, you can check its current state using the navigator.permissions.query() method from the Permissions API. This is useful both for deciding whether a user interaction is worth performing and for detecting when a user has previously blocked access.
const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
// Use the API.
}
Guiding users out of blocked states
If a user has blocked a capability, they may still reach a UI element that depends on it. In that case, use the Permissions API to check the state, and when it returns denied, present a troubleshooting dialog with instructions for changing the permission in the browser settings.
The steps vary by browser, so base your instructions on the user agent string. In Chrome, users can change permissions via View site information > Site settings from the address bar. In some cases, a page reload may be required before the capability can be used; when that happens, Chrome shows a message bar offering to reload.
Firefox and other browsers offer comparable permission management panels that can be pointed to in the same way.
