SiteVault

Capture assets of page loads — plus console log, HAR, storage & cookies — and save as a ZIP in original folder structure.

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 — never written to disk, cleared when the browser closes). Only traffic seen while DevTools was open on the inspected tab is captured — the webRequest listeners are registered on demand and torn down when the last DevTools window closes — so reload the page with DevTools open for a complete HAR; if nothing was captured, SiteVault falls back to the (redacted) getHAR() output and says so in log.comment. The HAR contains live session cookies and auth tokens — treat the ZIP as a secret and share it carefully. Storage (storage_*.json) — localStorage, sessionStorage and cookies for the inspected page. Same-origin only: storage is read from the page’s top frame; cookies are fetched by the background worker scoped to the page URL and re-checked against the host so no other domain’s data can leak in. Install (unpacked) Open chrome://extensions/. Enable Developer mode (top-right). Click Load unpacked and select this folder. Open DevTools on any http/https page and switch to the SiteVault tab. For the most complete capture, open the Network panel once and reload the page so every request and console message is recorded, then Save as ZIP. Permissions storage — remember your toggle choices, and hold the captured HAR entries in chrome.storage.session (memory only) until save time. cookies + host access — read the inspected page’s own cookies for the storage export. (Host access is used only for that; bodies are never re-fetched.) webRequest — observe the inspected tab’s own requests (method, URL, full request/response headers including Cookie / Authorization / Set-Cookie, request bodies, status and timing) so the HAR can be built directly from them instead of the redacted getHAR(). Traffic is read passively; webRequest here cannot block or modify any request. The listeners exist only while a DevTools window is open and record only inspected tabs — with DevTools closed, nothing is observed and Chrome’s network fast path is untouched. Files manifest.json extension manifest (MV3) devtools.html/.js registers the DevTools panel; opts the inspected tab in to capture (console wrapper + session port) panel.html/.css/.js the panel UI and save pipeline background.js service worker — reads page cookies + builds the complete HAR from chrome.webRequest while a DevTools session is connected lib/zip.js in-browser ZIP writer (CompressionStream + CRC32) lib/paths.js URL -> folder path resolution + de-duplication lib/tree.js folder/file picker (build tree + checkbox render) lib/beautify.js optional, dependency-free code formatter lib/network-capture.js no-refetch capture of network response bodies lib/console-capture.js injectable MAIN-world console wrapper source lib/extras.js console log / HAR / storage / network-response items icons/ toolbar / panel icons Copy