Known Limitations

Inspector Lab - DevTools brings full DevTools-style inspection to any browser and device that supports Manifest V3 extensions. However, some capabilities require browser APIs or permissions that are architecturally unavailable to in-page inspectors, and others depend on site configuration or browser support. This page documents the boundaries you'll encounter.

Architecture & API constraints

Console and network capture from page boot

To capture console.log and network requests from the moment the page starts loading — including before any user interaction — Inspector Lab requires the per-site permission grant. With that grant enabled, the capture wrapper installs at the document_start lifecycle hook, intercepting logs and requests before any page script runs. Early entries are buffered and replayed the moment you open the inspector.

Without the per-site grant, capture begins only when you launch the inspector, so logs and requests that fired during page load are lost. This is a fundamental limitation of when content scripts can inject: if you see an empty console after a reload on a site where you haven't granted permission, grant it and reload again.

Response body capture

Inspector Lab captures request and response bodies for fetch() and XMLHttpRequest only, capped at 20 KB per body. Static resources — documents, stylesheets, images, fonts — expose their headers, status, and timing via the webRequest API, but not their contents. Full-body capture for every resource would require chrome.debugger, which displays a permanent warning banner in the browser UI and is unsuitable for a non-blocking inspector.

Forced element states and cross-origin stylesheets

When you force an element state (:hover, :focus, :active, :focus-visible, :focus-within), Inspector Lab re-applies CSS rules for that state by inserting temporary pseudo-class selectors into the page's own stylesheets. This works perfectly for same-origin stylesheets, whose rules are readable and modifiable from an in-page context.

Cross-origin stylesheets loaded with CORS headers cannot be read or rewritten by page-world JavaScript, so their :hover and :focus rules are skipped when you force a state. The element's own styles and same-origin rules apply normally.

Console evaluation and Content Security Policy

Inspector Lab evaluates expressions in the page's JavaScript context by executing them with eval() in the page's main world. If a site's Content Security Policy forbids eval, console evaluation is disabled. Unlike Chrome DevTools, which operates at the debugger protocol level and can bypass CSP, an in-page inspector respects the same restrictions as page scripts.

When CSP blocks eval, the console input remains visible but disabled, with an explanatory message instead of failing silently.

Per-site permissions and navigation

Inspector Lab's state — including the inspector window itself — survives same-origin reloads and navigations reliably on sites where the per-site permission was granted. Without that permission, the inspector's ability to survive reloads depends on the page's reload mechanism and is not guaranteed across all navigation types.

Cross-origin and protected content

Cross-origin iframes

Inspector Lab cannot inspect the contents of iframes that point to a different origin. The DOM tree shows the iframe element itself, but the inspector cannot read or edit the document inside it — that would require a separate content script injected into each frame's origin, and permissions for each one.

Protected pages

Pages under chrome://, the Chrome Web Store, and other browser-protected origins are inaccessible to extensions. Inspector Lab cannot launch on these pages at all.

Platform-specific limitations

iOS and iPadOS (Orion browser)

Inspector Lab runs on Orion by Kagi, a free WebKit-based browser for iPhone and iPad that runs Chrome extensions. However, iOS and iPadOS restrict the extension API surface, so some panels fall back to in-page sources and label themselves accordingly:

• Console evaluation uses an injected page script instead of the background service worker, since chrome.runtime.sendMessage and the debugger APIs are unavailable.
• Cookie table reads document.cookie as a fallback, which cannot see HttpOnly cookies and only exposes names and values — all other columns (Domain, Path, Expiry, SameSite, Secure, HttpOnly) display a dash.
• Network panel still captures live fetch/XHR requests, but loses the webRequest API's log of static resources (documents, stylesheets, images, fonts).
• Elements, Sources, and Storage panels work at full strength.

These fallbacks are automatic and labeled on screen — there is no configuration needed, but you should be aware that some inspections are less complete on iPad than on desktop.

Out of scope by design

Some DevTools features require the chrome.debugger protocol or demand persistent browser-level state that conflicts with the inspector's philosophy of being harmless to the page:

• Breakpoints and step debugging — requires chrome.debugger and a permanent warning banner.
• Profiling and performance recording — requires chrome.debugger.
• CSP bypass — possible only with debugger protocol; eval-blocked sites stay blocked.
• Permanent attribute modifications — the inspector edits the live DOM, not saved source files, so changes vanish on reload (this is intentional — you're inspecting, not developing into a page).
• DOM breakpoints — watching the DOM tree for mutations requires chrome.debugger.

These are out of reach not because of a gap that might be filled, but because they conflict with the core design: Inspector Lab is a non-intrusive inspection tool, not a full development environment.

Other edge cases

iPad Smart Punctuation in console input

iOS Smart Punctuation automatically replaces straight quotes with curly ones ("log" → "log") and converts character sequences like i-- into em-dashes (i—). Valid JavaScript rejects curly punctuation in source code. Inspector Lab detects when Smart Punctuation breaks an expression and automatically retries it with straightened characters — but only then, so a curly apostrophe inside a valid string is never rewritten.

Large or pathological files in Sources

To protect against pages that define thousands of inline scripts or hugely oversized stylesheets, the Sources panel enforces a 60 KB / 2,000-line cap per file. If a file exceeds this limit, it is truncated and a message in the status bar explains why. This prevents a single malformed page from freezing the inspector.

File tree depth and complexity

The file tree organizes sources by host and URL folder, following DevTools' navigator structure. Pages that dynamically generate thousands of unique URLs or define an unusually deep nesting can make the tree slow to expand. This is rare, but if you encounter it, a refresh clears the tree and you can selectively open only the files you need.

Still need more?

If a limitation blocks your workflow, check whether the inspector is the right tool for your task — some inspections genuinely do require the debugger protocol or a full IDE. For bugs or feature requests, open an issue on GitHub.