SiteVault

SiteVault A Chrome DevTools panel that captures everything a page loads and saves it into a single ZIP that mirrors the site’s original folder structure — page resources plus, optionally, the console log, a network HAR, page storage, and every network-tab response. What it does Adds a SiteVault panel to Chrome DevTools. Collects the page’s Sources resources, de-duplicates them, and rebuilds their folder paths. Nothing is ever re-fetched — bodies come straight from what DevTools already holds, so they match exactly what the page received. Re-hydrates empty bodies. Resources often appear in the Sources tree before DevTools has loaded their body, so getContent returns nothing. Before saving, SiteVault retries getContent over a few short passes for every still-empty resource — this is what reliably pulls in third-party / CDN minified JS that you can see in the tree but that used to save empty. Keeps binary network bodies too. The Network-tab capture no longer drops base64/binary responses, and any URL ending in a code/text extension (.js, .mjs, .css, .json, .map, .wasm, …) is kept even when the CDN serves it with a generic or wrong MIME type. Pick what to export. Saving now opens a collapsible folder tree with a checkbox on every folder and file (with per-folder counts and sizes). Tick or untick whole domains / folders / individual files, then Save as ZIP — only what you selected is packed. Folder checkboxes cascade and show a tri-state when partially selected. Compresses everything client-side (native CompressionStream) and downloads <hostname>.zip. No external libraries, no network calls of its own. Zero overhead while DevTools is closed. All capture is opt-in per DevTools session: the console wrapper is injected only into inspected pages, and the webRequest HAR listeners are registered only while a DevTools window is open (and record only inspected tabs). The tradeoff: capture starts when DevTools opens, so reload the page with DevTools open to get the console log and HAR from the very start of the load. Tip: to grab everything from another domain (e.g. a CDN), turn “Exclude resources from other domains” off, then deselect anything you don’t want in the picker. The picker makes per-domain trimming easy without the toggle. Filters & extras (toggles) Toggle Default Skip empty (no-content) files off Beautify HTML / CSS / JS / JSON off Exclude images on Exclude audio & video on Exclude .txt files on Exclude fonts on Exclude resources from other domains on Include network-tab responses (merged, no re-fetch) on Include console log on Include network HAR (with content) on Export localStorage, sessionStorage & cookies on Toggle state is remembered between sessions. The extras, in detail Network-tab responses (no re-fetch) — text response bodies read from the DevTools network log via getContent() and merged into the same <host>/… tree. URLs already saved from Sources are skipped to avoid duplicates; a _network/_manifest_*.txt records what was kept and skipped. Binary bodies are left to the regular Sources save; nothing is re-requested. Console log (console_*.log) — console.* calls captured by a MAIN-world wrapper that the DevTools page injects when DevTools opens (and re-injects on every navigation), plus onerror / unhandledrejection, interleaved with one line per network request rebuilt from the HAR. Capture starts when DevTools opens — reload the page with DevTools open to record from the very start of the load. Pages that aren’t being inspected never run the wrapper. The file header explains what a panel-based capture can and cannot see versus Chrome’s native “Save as…”. The in-page buffer is strictly bounded (8 KB per message, 5,000 messages, ~4 MB total; oversized logged objects are truncated during serialization), so pages that log huge objects in a loop can no longer exhaust the renderer’s memory — the cause of DevTools’ “Debugging connection was closed. Reason: render process gone.” Network HAR (network_*.har) — a complete HAR 1.2 export, the equivalent of DevTools’ “Copy all as HAR (with sensitive data)”. SiteVault deliberately does not use chrome.devtools.network.getHAR(): that API strips response bodies and redacts the Cookie, Authorization and Set-Cookie headers unless you flip “Allow to generate HAR with sensitive data” in DevTools settings — the exact limitation this export is meant to avoid. Instead the background worker assembles the HAR itself from chrome.webRequest, which (with extraHeaders) exposes the real headers as they are actually sent and received. Nothing is redacted, and no DevTools setting has to change. Correlated by requestId. Every header attaches to the exact request it came from, and each redirect hop is preserved as its own entry — so a Set-Cookie issued on a 302 (common in auth flows) and the Cookie sent on the request that follows are both kept, on the right entries. Response bodies. The one thing webRequest cannot read is the response body; those are merged in from the DevTools network log (getContent(), no re-fetch) at save time — text as-is, binary as base64. Every response is captured per request, and each body attaches only to the entry whose URL, method, status and start time match — repeated requests to the same URL (polling, GraphQL, reloads) each keep their own body, and an entry whose body wasn’t captured stays empty rather than borrowing another response’s body. Companion Chrome HAR (network_*_chrome.har) — Chrome’s own getHAR() output saved verbatim alongside SiteVault’s HAR, so the two captures can be compared side by side. (Note Chrome strips bodies here and redacts Cookie / Authorization / Set-Cookie unless the DevTools “Allow to generate HAR with sensitive data” setting is on.) Integrity summary. The HAR’s log.comment records the source, the entry count, how many entries carry a response body, and how many carry sensitive data, so the export’s completeness is auditable at a glance. Captured records live in chrome.storage.session (memory only — ne…