Site permissions in Chrome control what each website can access: your location, camera, microphone, whether it can send you notifications, whether pop-ups open, whether it can read your clipboard. Managing them well is one of the more practical privacy improvements available — sites accumulate permissions over time, and most users don’t review them until something goes wrong. This fits into the wider topic we cover in our How to Manage Google Chrome.
The main hub for all permissions: chrome://settings/content. This single page contains every permission category Chrome manages. Think of it as the master control panel — you can see defaults for each type and drill into any category to see which specific sites have been granted or blocked.
The fastest access method — the address bar lock icon
While visiting any website: click the lock icon (or information icon) in the address bar → Permissions. This shows every permission for that specific site — location, camera, notifications, etc. — and lets you change them immediately without navigating to settings. This is the fastest way to review or change permissions for a site you’re currently on.
If a site has been granted something you didn’t intend: change it here in seconds. The change takes effect immediately; no page reload required for most permission types (notifications and some device access may need a reload).
What each permission type actually enables
- Location: the site receives your device’s GPS coordinates or network-estimated position. Accuracy varies from metres (GPS) to city-level (IP-only). Weather and maps sites have legitimate needs; most others don’t.
- Camera: the site can activate your webcam. Active sessions show a recording indicator in the Chrome tab and the Windows system tray.
- Microphone: the site can access your microphone input. Required for video calls, voice search, online recording tools.
- Notifications: the site can push desktop notifications that appear outside the browser window. Most users should block this by default and allow only specific services.
- Pop-ups and redirects: the site can open new browser windows or tabs automatically. Chrome blocks this by default; whitelisting is for sites that legitimately open content in new windows (some payment flows, government forms).
- Clipboard (read): the site can read your clipboard contents. Password managers and code collaboration tools may need this; random websites shouldn’t.
- Automatic downloads: the site can initiate multiple downloads without prompting for each. Relevant for software distributors or archive sites.
Reviewing what sites currently have access
chrome://settings/content → click each permission type → see “Allowed” and “Blocked” site lists. The most useful categories to review periodically: Notifications (often the longest “Allowed” list with many forgotten entries) and Location (high privacy sensitivity).
The “All sites” view at the bottom of chrome://settings/content shows every site that has any stored permission state, with a summary of what each site has been allowed. This gives the broadest overview without clicking through each category individually — useful for a periodic full review.
Setting global defaults vs per-site exceptions
Each permission type has a global default (“Sites can ask” or “Blocked for all sites”) and then per-site exceptions. The defaults apply to any site not specifically listed. Exceptions override the default for that specific site.
Recommended defaults for most users:
| Permission | Recommended global default |
| Location | Sites can ask (prompts you each time) |
| Camera | Sites can ask |
| Microphone | Sites can ask |
| Notifications | Don’t allow sites to send notifications (block by default) |
| Pop-ups and redirects | Don’t allow sites to send pop-ups (Chrome default) |
| Clipboard (read) | Sites can ask |
Blocking notifications globally then manually adding exceptions for services you actually want notifications from (calendar, project management, messaging) is more effective than trying to deny each new prompt individually.
Resetting permissions for a site
If a site’s permissions got into a messy state: visit the site → lock icon → Permissions → at the bottom of the permissions panel, “Reset permissions” returns that site to the global defaults. This is faster than finding and removing each permission type manually from the settings pages.
For a complete permission reset across all sites for one type: chrome://settings/content → click a permission (e.g., Notifications) → “Reset permissions” clears all stored decisions for that type. Every site starts fresh and must request permission again.
Our guide on Chrome privacy settings covers what data Chrome stores beyond permissions, and our camera and microphone access control covers those specific permissions in more depth including system-level controls. For technical details on each permission’s scope and how browsers implement them, Chrome’s web platform documentation covers the Permissions API and how sites request access.
Permission inheritance and iframes
Permissions granted to a main site (example.com) don’t automatically extend to embedded content from other domains loaded in iframes on that page. If a site embeds a video player from another domain, and the video player needs microphone access: that second domain needs its own permission, not just the main site.
This is why you sometimes see two separate permission prompts on one page. The first is from the main site; the second is from embedded content. Chrome shows both origins in the prompt — reading the permission prompt’s domain name carefully tells you which exact service you’re granting access to, not just which page you’re visiting.
Site permissions on mobile Chrome
Chrome on Android and iOS: permissions work similarly but the access path differs. In Android Chrome, site permissions are accessible through the three-dot menu → Settings → Site settings. On iOS, site-specific permissions appear via the information icon in the address bar. The management interface is less feature-rich than desktop Chrome, but the same permission categories exist and can be reviewed and revoked.
Android additionally has system-level app permissions for Chrome itself (Settings → Apps → Chrome → Permissions), which control whether Chrome the app can access location, camera, or microphone at all. A site permission in Chrome for Android only works if the system-level app permission for Chrome also allows it — two layers that must both be enabled for device access to work.
The “All sites” page at chrome://settings/content is the underused tool for efficient permission management. Most users never visit it. Spending five minutes there periodically — removing sites you no longer use from the Notifications allowed list, revoking location from sites that don’t need it — keeps Chrome’s permission state clean and prevents the gradual accumulation of access grants that you forgot you made.
Permissions and Chrome profiles
Site permissions are profile-specific. A permission granted to a site in your Work Chrome profile doesn’t exist in your Personal profile, and vice versa. If you use separate profiles for different contexts: manage permissions independently in each one. A site that has camera access in the Work profile for video calls doesn’t automatically get it in the Personal profile just because the same browser is installed.
This is actually useful — your work profile can have corporate tools’ permissions fully configured, while your personal profile has stricter defaults that sites in your personal browsing haven’t accumulated. Profile separation is one of the more effective privacy management tools Chrome offers, and site permission isolation is part of what makes that separation meaningful.
Permissions for Progressive Web Apps (PWAs)
Installed web apps (PWAs) — sites like Spotify Web, Twitter/X, or Notion installed as apps via Chrome’s “Install page as app” option — have their own permission entries separate from visiting the same URL in a browser tab. The PWA’s permissions appear in the OS application manager alongside desktop app permissions.
On Windows: Settings → Apps → find the PWA → a “Permissions” section shows location, camera, and microphone access for that installed app specifically. These are managed both in Chrome’s site permissions and in Windows app permissions. If a PWA isn’t getting a permission it needs: check both Chrome’s settings and Windows’ app permissions for that PWA entry.
Enterprise and managed Chrome permission controls
IT-managed Chrome installations can have permissions pre-configured via Google Admin Console or Group Policy. Common enterprise permission configurations: forcing specific sites to always have certain permissions (corporate video conferencing tools pre-allowed for camera/microphone), or blocking categories entirely (no site can request location on managed devices).
If a permission appears locked (greyed out or always reset to a specific state after you change it): a policy controls it. chrome://policy shows active policies including content-setting policies. “DefaultLocationSetting,” “DefaultCameraAllow,” and similar policy names explain which permissions have policy-level controls. Users on managed devices can’t override these without admin rights — intentional for security management purposes.
Cookie-related site settings
The Site settings in chrome://settings/content also include cookies, which technically function as a per-site permission. chrome://settings/content/cookies shows sites in the “Always clear cookies when windows are closed” list (Chrome deletes that site’s cookies each session) and sites that are “Always allowed” regardless of global cookie settings.
This is where exception-based cookie management lives. If you want to always clear cookies for social media sites while keeping them for banking sites: add social media to the “Always clear” list and banking sites to the “Always allowed” list. This more targeted approach preserves logged-in sessions for trusted sites while ensuring privacy-sensitive sites start fresh each session.
Site permissions are Chrome’s granular privacy control layer. They’re more targeted than the global privacy settings — they let you allow specific sites the access they legitimately need while maintaining tighter restrictions everywhere else. The address bar lock icon and the chrome://settings/content hub together give you two access points for the same underlying permission system: one for quick per-site changes and one for the broader review of what’s been accumulated over time.
When sites keep asking for the same permission
If a site repeatedly prompts for a permission you’ve already answered: there are a few possible explanations. First, clicking outside the prompt or pressing Escape often dismisses without creating a permanent decision — the site can prompt again on the next visit. To make the decision permanent: click “Block” or “Allow” explicitly in the prompt rather than dismissing it.
Second, some sites use aggressive permission request patterns: they prompt on load, and if you dismiss the prompt, they immediately prompt again. This is an annoying but legal design pattern — Chrome’s “Quieter notifications” feature handles this for notifications by showing a smaller indicator instead of the full prompt after a site is identified as aggressively requesting. For other permission types: blocking the site explicitly in chrome://settings/content prevents further prompts.
Permissions and HTTPS requirement
Chrome only grants sensitive permissions (camera, microphone, location) to HTTPS sites. Sites without HTTPS (http:// rather than https://) can’t request these permissions — Chrome silently denies them without a user-facing prompt. If a site on HTTP tries to access your camera: it will fail without you ever seeing a permission request, and from your perspective it “doesn’t work.”
This is a security feature: non-encrypted connections are vulnerable to interception, and granting camera or microphone access over HTTP would expose that audio/video stream. Legitimate services requiring these permissions use HTTPS. If a site on HTTP complains it can’t access your camera or microphone: the lack of HTTPS is the reason, not Chrome’s permissions settings. The site owner needs to implement HTTPS — there’s no user-side workaround for this by design. Our guide on How to Manage Chrome Downloads covers an adjacent issue.
Understanding the two-tier structure of Chrome permissions — global defaults that apply to everything, per-site exceptions that override defaults — makes managing them intuitive. Change the global default to what makes sense for most sites, then add specific exceptions for sites with legitimate but unusual needs. Reviewing those exceptions periodically (especially the Notifications allowed list) keeps the system clean without needing to think about permissions on every new site visit. See also How to Manage Chrome Extensions for a related case.
One helpful framing for permissions decisions: ask whether the permission is needed for a feature you’re actively using on that site. A maps service needs location to show your position on the map — that’s the feature. A news site asking for location is using it for something you didn’t ask for and probably don’t want. Camera access for a video call tool is the feature. Camera access on a recipe site is not. The permission prompt itself is the opportunity to make this judgment call, and the address bar lock icon gives you the ability to revisit it at any time after the initial decision. You might also run into How to Control and Manage Site Permissions in Google Chrome.
