Using Chrome Internals Pages for Extensions

The service worker will not start and DevTools has nothing to show. A content script runs on one machine and not another. An enterprise user’s extension behaves as if a setting were forced. The normal DevTools workflow cannot answer these, because the problem is in how Chrome itself sees the extension — its permissions, its worker registration, its policy, its process. Chrome exposes that internal state through chrome:// diagnostic pages. Few developers know more than chrome://extensions, but a handful of others answer questions nothing else can. This guide tours the useful ones. It belongs to debugging extension contexts.

The pages and what they answer

Each internals page answers a specific question. chrome://extensions (with Developer mode) is the control centre: reload, errors, service worker link, ID. chrome://extensions-internals dumps Chrome’s full internal record of every installed extension as JSON — granted and withheld permissions, active host patterns, manifest, install location, disable reasons. chrome://serviceworker-internals lists every service worker registration with its running status and lets you start, stop and inspect them. chrome://inspect/#extensions lists inspectable extension targets. chrome://policy shows enterprise policies, including ExtensionSettings and managed storage. chrome://net-export records network activity for offline analysis. The Task Manager shows each extension’s memory and CPU.

Step-by-step: the internals toolkit

1. Read effective permissions in extensions-internals

1chrome://extensions-internals
2→ find your extension id
3  "permissions": {
4    "active":    { "api": ["storage","scripting"], "explicit_hosts": ["https://news.example/*"] },
5    "withheld":  { "explicit_hosts": ["<all_urls>"] },
6    ...
7  }
8  "disable_reasons": [], "location": "UNPACKED", "manifest_version": 3

Execution context: Chrome. This page is the ground truth for “does the extension have access to this site?”. withheld hosts mean the user restricted site access; active hosts are what is actually granted. When a content script runs for one user but not another, compare this section between their machines. disable_reasons explains why an extension is disabled (for example, a permissions increase awaiting approval). See handling user-restricted site access.

2. Control the worker in serviceworker-internals

On chrome://serviceworker-internals, find the registration whose scope is chrome-extension://<id>/. It shows Running Status (RUNNING / STOPPED), the script URL, and buttons to Start, Stop and Inspect. Stopping the worker on demand is the simplest way to test that your extension survives termination — state rebuilt from storage, listeners registered at the top level, alarms intact. Check “Open DevTools window and pause JavaScript execution on Service Worker startup for debugging” to break on the first line of a worker that fails during startup. See debugging a service worker that won’t start.

3. Find every target in chrome://inspect

chrome://inspect/#extensions lists the extension’s inspectable contexts: the service worker, offscreen documents, open extension pages, and background pages of MV2 extensions. Offscreen documents are easy to forget — they do not appear on chrome://extensions, and this is the place to inspect them. See finding the right DevTools target for each context.

4. Check enterprise policy

1chrome://policy
2  ExtensionSettings: { "abcdef…": { "installation_mode": "force_installed", "blocked_permissions": ["history"] } }
3  3rdparty → extensions → abcdef… : { "apiEndpoint": "https://corp.example/api" }    ← managed storage

Execution context: Chrome on a managed machine. Policies can force-install the extension, block specific permissions (making permissions.request fail), restrict runtime host access (runtime_blocked_hosts), and supply storage.managed values. When an enterprise customer reports behaviour you cannot reproduce, ask for a screenshot or export of this page first. See configuring extensions with enterprise managed storage.

5. Capture network activity with net-export

chrome://net-export records a log of all network activity — including requests from extension service workers, which can be awkward to catch in DevTools because the worker may stop. Start logging, reproduce the problem, stop, and open the JSON in the NetLog viewer (netlog-viewer.appspot.com). It shows DNS, proxy, TLS and redirect details that explain “the request fails only on the corporate network”. Logs can contain sensitive data; choose “Strip private information” when users send them to you.

6. Measure resource use with the Task Manager

Open it from the browser menu → More tools → Task Manager (Shift+Esc on Windows and Linux). Each extension’s service worker, offscreen document and pages appear as rows with memory footprint and CPU. A worker that never drops to zero CPU, or memory that grows over hours, points to a leak or a busy loop. See auditing extension impact with the task manager.

7. Other pages worth knowing

chrome://version shows the exact Chrome version and command-line flags (useful in bug reports). chrome://flags lets you test upcoming extension behaviour behind flags. chrome://process-internals shows site isolation and which process hosts which frame, which occasionally explains content-script behaviour in cross-origin iframes. chrome://sync-internals shows sync activity, including extension settings sync.

8. Collect a diagnostics bundle from users

1support-request-template.md
21. chrome://version  → copy the first three lines (Chrome version, OS, JavaScript engine)
32. chrome://extensions-internals → find "Readable" → copy its block only
43. chrome://policy → screenshot, or "Export to JSON" and remove unrelated entries
54. chrome://extensions → Readable → Errors → screenshot
65. Steps to reproduce, and whether it happens in a new profile

Execution context: your support process. A short, consistent request turns “it doesn’t work” into evidence you can act on: the exact browser build, the extension’s effective permissions and disable reasons, any policies applied, and recent errors. Asking whether the problem happens in a fresh profile separates environment issues (policy, other extensions, corrupted profile data) from bugs in your code. Keep the request specific to your extension so users are not asked to share their whole browser state.

Common mistakes

• Guessing permissions from the manifest. Read the effective state in extensions-internals.
• Not testing worker termination. Use Stop on serviceworker-internals.
• Forgetting offscreen documents. Inspect them from chrome://inspect.
• Ignoring policy for enterprise bugs. Check chrome://policy first.
• Sharing unredacted net-export logs. Strip private information.

Cross-browser variation

• Chrome / Edge: all pages above; Edge uses edge:// equivalents (edge://extensions-internals, edge://serviceworker-internals, edge://policy).
• Firefox: about:debugging for targets and workers, about:policies for enterprise policy, about:performance for per-extension resource use, about:networking for network logging.
• Safari: the Develop menu and Web Inspector; Safari has no equivalent of extensions-internals — check Safari Settings → Extensions for permissions.

Verification

1. Restrict site access to “On click” and confirm the hosts move to withheld in extensions-internals.
2. Stop the worker on serviceworker-internals and confirm the next event starts it.
3. Open an offscreen document and find it on chrome://inspect.
4. Record a net-export log while the worker syncs and find its requests in the viewer.

FAQ

Are internals pages stable?

Their layout changes between versions; the information is usually still there. Don’t automate against them.

Can users open these pages?

Yes — they are available in every Chrome install, which makes them useful for remote support.

Is extensions-internals safe to share?

It lists all installed extensions and their permissions. Ask users to copy only your extension’s entry.

Can I link to these pages from my extension?

Extensions can open most chrome:// pages with chrome.tabs.create, which is handy for a “Troubleshooting” link in options. Web pages cannot link to them directly.

Which page shows why an extension was disabled?

chrome://extensions-internals lists disable_reasons — for example a permissions increase awaiting approval, corruption, or policy. The extensions page shows a summary; the internals page shows the exact reason codes.

Related

• Finding the right DevTools target for each context — inspecting contexts.
• Debugging a service worker that won’t start — worker startup.
• Reading errors from the extensions page — the Errors view.
• Debugging extension contexts — the parent topic.