Features
Archivepanel is deliberately narrow: it captures pages faithfully, files them privately, keeps them unchanged, and refuses to trap them. What follows is what that means in practice.
Capture fidelity
A capture drives a real browser, waits for the page to settle, and writes a single document with every stylesheet, image and font embedded as a data URI and unused CSS pruned away. Scripting is stripped, and a content policy is embedded in the saved file so an opened archive cannot reach the network even if something were left behind. The browser runs at a 1440×900 viewport; video and audio are not captured.
A saved page that scatters assets across a folder is a snapshot with moving parts. Move it, mail it, put it in evidence storage, and half of it stops resolving. One document has nothing left to lose.
Faithfully embedding a modern page — responsive image sets, shadow DOM, custom properties — is a hard problem. Archivepanel drives headless Chromium through SingleFile rather than pretending a hand-rolled inliner is equivalent.
The preview image is a screenshot of the saved file, never of the live page. A capture that lost its styling therefore looks wrong in your archive list on day one, instead of looking fine until someone opens it in year three.
A cookie banner is the usual reason a capture records nothing useful: it covers the page, and nearly all of them lock scrolling while they are up, so the lazily loaded content below the fold is never fetched either.
Where a known consent platform is recognised, its own accept control is pressed — which is also the only thing that reveals a page genuinely gated behind consent, rather than merely covered by it — and its container is dropped from the saved document.
Every selector names one platform's own control. There is deliberately no "looks like a banner" pass: a heuristic that hides whatever floats and mentions cookies eventually takes a piece of the page with it. A banner left standing is a worse archive; a missing masthead is a wrong one. The record states that consent was auto-accepted, so the snapshot is honest about how it was taken.
Stored files
| File | Produced from | Purpose |
|---|---|---|
| .html | The live page | The archive itself. Self-contained, script-free, offline-renderable. |
| .jpg | The saved file | Verification and recognition. Shown on the record and beside each row in the archive list. |
| .txt | The saved file | Reading, quoting, grepping, diffing. Served from the dashboard itself, since it is text we generated rather than captured markup. |
| .warc.gz | All three | Interchange. One download carrying the document, the text rendering and the screenshot together. |
| .json | All of the above | Audit and inventory. A size, a SHA-256 digest and a content type for every stored file, plus the addresses, times, viewport and tool versions behind the capture. |
Text snapshots
Every capture is also converted to structured plain text — from the bytes just saved, not from the live page, so the text and the archive can never disagree about what the page said.
It keeps the structure worth keeping and drops what carries no readable text: inline SVG, hidden elements, template bodies, and the data URIs that would otherwise print megabytes of base64 mid-sentence.
The text opens in the dashboard with a find box that matches as you type, highlights every occurrence and steps between them with Enter and Shift+Enter. It runs entirely in your browser over text the page already holds — no request per keystroke, and what you search an archived document for is never sent anywhere. Snapshots are shown up to 512 KB, with the whole file a download away.
Finding things again
Three ways in, each answering a different question: which snapshot, which site, and which passage.
Title, address and host are searched a word at a time — every word you type must appear somewhere, in any order, so nos italie finds the article about Italy on nos.nl. Filter by status, and sort by newest, oldest, largest, title or site.
Every snapshot you hold, grouped by host — the view to use when you want the history of one place rather than one page, and the way to see how often a site has been captured and when it last was.
Searching within a site reads the stored text of that site's snapshots and shows the passage that matched, so a page can be found by something it said rather than by its title.
Scheduled captures
A page schedule captures its own address, one archive per run. A sitemap schedule reads its address as an XML sitemap and captures the pages that sitemap lists — so one schedule covers a whole section of a site, and keeps covering it as the site adds pages.
Hourly, daily, weekly or monthly. A run is skipped while the previous one is still draining, so a slow site cannot pile work on itself.
Both sitemaps.org document types are understood — a urlset listing
pages, and a sitemapindex pointing at further sitemaps, followed one
level down. The gzipped form is decompressed transparently, detected by
content rather than by file extension, because servers are inconsistent about both.
| Bound | Value | Why |
|---|---|---|
| Pages per run | 20 default, 100 max | Set per schedule when it is created. |
| Sitemap files read | 12 | An index pointing at hundreds of children costs twelve requests, not hundreds. |
| Document size | 12 MB | After decompression. |
| Whole traversal | 45 s | A sitemap that will not resolve does not hold a worker. |
| Outstanding captures | 5 | A run is skipped rather than queued behind itself. |
WARC export
Every capture is packaged as a WARC file (ISO 28500, WARC 1.1) alongside the document. The same bytes open in pywb, replay through ReplayWeb.page, and satisfy an institution that accepts nothing else.
It is offered as a download from the record page rather than as a view — it is a file for other tools, not something a browser renders. Packaging happens after the document is saved and costs no second visit to the site.
Its metadata record is the JSON manifest itself rather than a summary of it, so one download carries the tool versions, the viewport, the timings, what the page declared about itself, how its host resolved, and a digest for every file the capture produced. Two accounts of one capture are two things that can come to disagree.
| Record | Contents |
|---|---|
| warcinfo | Software, format version, user agent, and the page list replay tools need |
| response | The saved document, as an HTTP response block |
| metadata | The JSON manifest in full, byte for byte, tied to the document it describes |
| conversion | The plain-text rendering |
| resource | The preview image |
Progress and notifications
Status, stage and an elapsed-time progress bar update in place while a capture runs, and the record page refreshes itself once the capture settles. Polling backs off when nothing is running and stops entirely in a background tab.
When a capture is stored, fails, or is stopped by a storage limit, a notification goes to the tray in the masthead with an unread count — and arrives as a toast if you happen to be looking at the time.
Security and privacy
A service that fetches addresses on request and later renders the result in your browser has two distinct problems: it must not be usable as a way into our network, and a captured page must not be able to act inside your account.
Storage and limits
Each account has a snapshot storage allowance — 50 MB by default. Usage counts every file a capture stores, since all of them occupy the bucket. Your current usage is on the dashboard, not buried in a settings page.
Create an account, paste an address, and see the snapshot — document, preview, text, WARC and manifest — land in your archive.