# Known Limitations Source: https://inspectorlab.dev/limitations > For the complete documentation index, see [llms.txt](https://inspectorlab.dev/llms.txt). # 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](https://help.kagi.com/orion/browser-extensions/ios-ipados-extensions.html), 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](https://github.com/luangjokaj/inspector-lab).