Documentation

01Getting started

Create an account at dashboard.archivepanel.com/register. Your email address is your account identifier — there are no usernames. Registration finishes by entering a six-digit code sent to that address, so an address that cannot receive mail cannot complete sign-up.

Every later sign-in is the same two steps: password, then a six-digit code — emailed to you, or read from an authenticator app once you have set one up. A passkey replaces both steps. A proof-of-work check runs on the sign-in and registration forms and solves itself as the page loads; there is nothing to click and no puzzle to read. Account and security covers the options.

Once you are in, the Overview carries the capture box. Paste an address, press capture, and the first snapshot is on its way. The Overview is the dashboard's front page, at dashboard.archivepanel.com/. Under your recent captures it shows the next scheduled runs and the sites you have archived most recently, each with its snapshot count and when it was last captured.

02Capturing a page

The address is checked before anything is fetched: anything resolving to loopback, private, link-local, carrier-grade NAT or unique-local space is refused, and every redirect hop is checked again.

Capture then runs away from your request, one page at a time. A capture that arrives while another is running waits its turn, so a snapshot is queued before it is running. Most pages take a minute or two.

The turn is not strictly first come, first served. A capture somebody asked for by hand goes ahead of scheduled and sitemap work, and among the rest the account that has waited longest since its last capture goes next — so a large sitemap run on one account does not hold up everyone else’s captures behind it.

When an attempt fails

A failure another try could get past — a page that timed out, a host that did not resolve, a snapshot that could not be written to storage — is tried again, automatically: after 2 minutes, then after 10, for three attempts in all. While it waits the capture stays queued, and its progress card says which attempt failed, why, and when the next one starts. Only the last failure raises an alert or, for a scheduled capture, an email. A failure no retry can fix — an address that cannot be archived, a page over the size limit, not enough storage left — is reported at once.

A snapshot that took more than one attempt says so in its metadata.json, which also records when the browser was sent to the page as well as when the saved page was read back: the page the snapshot shows was loaded between those two moments.

While it runs

The progress card reports the stage in plain words — opening the page, waiting for it to finish loading, saving the text, images and layout, finishing the snapshot — with a bar estimated from elapsed time. The estimate is capped below 100% until the record actually says the capture is stored, because the underlying tool reports nothing until it is done.

You do not have to wait. Close the tab and a notification lands in the masthead tray with an unread count when the capture is stored, fails, or is stopped by a storage limit; if you happen to be looking at the dashboard it also arrives as a toast.

Stopping a capture

A queued or running capture can be stopped from the progress card, from the Actions column of the archive list, or from its record page. Stopping kills the browser immediately and writes nothing to storage, so a capture you abandon costs you no quota. It is recorded in the activity log, raises no failure alert, and sends no email.

03What a snapshot is

Capture drives a real Chromium at a 1440×900 viewport, waits for the page to settle, and writes one 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 wherever it ends up. Video and audio are not captured.

Where a cookie banner is recognised it is dismissed before the page is saved, so the snapshot is the page rather than the overlay — and the record says what was done about it.

The note at the top of the file

The saved HTML opens with a short comment, invisible when the page is viewed, so a copy that has left your account still says where it came from. Open the file in a text editor to read it:

<!--
 Archived by Archivepanel (https://archivepanel.com)

 requested url:  https://example.com/pricing
 final url:      https://www.example.com/pricing
 page opened:    2026-09-28T12:14:02Z
 page saved:     2026-09-28T12:14:31Z
 viewport:       1440x900
 browser:        Chromium 154.0.8037.57
 saved with:     single-file-cli 2.16.0
 consent rules:  autoconsent 16.42.0
-->

final url appears only when a redirect happened, and consent rules only when cookie-banner handling ran. Times are UTC; the page was loaded between the two. The comment is written before the document is digested and timestamped, so it is covered by both, and it holds nothing that is not also in metadata.json. Snapshots taken before 28 September 2026 carry SingleFile’s own shorter comment instead.

Five files are stored per capture:

04The archive record

Each snapshot has a record page. It carries what was asked for and where the browser actually ended up — the two differ whenever a redirect happened — along with the title, the capture time, the stored size, and who asked for it: you, a named member of your team, or a schedule.

Two further sections describe the page and the moment it was taken:

• What the page declared about itself — language, description, the canonical address it names, author and published date, where it states them.
• How the host resolved at that moment — the addresses it answered on, the CNAME it resolves through (often the only visible sign of a CDN), the authoritative nameservers, and the TLS certificate it served.

From there you can view the archive, download it, read the text rendering, take the WARC or the JSON manifest, download its trusted timestamp, capture the address again, or delete the record.

Tags and a note

Each record can carry up to twelve tags and a note of up to 2,000 characters. Tags group records across sites — a client, a matter, a review — and the archive list can be filtered by any of them. The note is for why the page was captured or what to look for in it. Both belong to the record, not the snapshot: adding or changing them never touches the stored file, its digest or its timestamp, and they are visible to everyone in the workspace.

05Trusted timestamps

The capture time on a record is our word for when a page was saved. A trusted timestamp is someone else’s. As each capture completes, the SHA-256 digest of the stored document is sent to an independent timestamping authority, DigiCert, which signs a statement that a file with exactly that digest existed at that moment. The signed token (RFC 3161) is kept with the record.

• Only the digest leaves the service. The authority never sees the document, its address or your account.
• Every token is checked on arrival: that it covers the digest we sent, answers our request and no earlier one, carries a valid signature, and chains to a public root through a certificate issued for timestamping.
• It does not rely on trusting us. Anyone holding the downloaded document and its token can check it with standard tools, years from now and without an account.

The record page shows the certified time, the digest and the token’s serial number, with the token and the document one click each. To check them yourself, put both files in one folder and run OpenSSL:

openssl ts -verify -data example.com-20260923-1600.html \
  -in example.com-20260923-1600.tsr -token_in \
  -CAfile /etc/ssl/certs/ca-certificates.crt

It prints Verification: OK only when the signature, the certificate chain and the file’s digest all agree. Change one byte of the document and it fails.

Kept checkable for decades

A token can be checked for as long as the authority’s certificates behind it are valid, which is roughly ten years. In the year before they expire, we renew the timestamp automatically: the authority timestamps the token itself while it still verifies. The newer token proves that the original existed while its certificates were good, and in turn it gets renewed before its own certificates expire. Each renewal adds one link to the chain, about once a decade, and the original proof carries through.

• Nothing new leaves the service. A renewal sends the SHA-256 of the previous token, which is public evidence anyway.
• Revocation is recorded. With each renewal we keep the certificate authority’s signed revocation list from that time. It shows that the certificate behind the renewed token had not been revoked. A token whose certificate has been revoked is never renewed.
• Nothing to do. The record page shows when the current certificates expire and lists every renewal, and each renewal token and revocation list can be downloaded.

Check each link against the file it covers. -attime checks a token’s certificates as of the moment the next renewal was made, so the chain still holds after they expire. The record page prints these commands with the right file names and times filled in.

openssl ts -verify -data example.com-20260923-1600.html \
  -in example.com-20260923-1600.tsr -token_in -attime 2091744000 \
  -CAfile /etc/ssl/certs/ca-certificates.crt
openssl ts -verify -data example.com-20260923-1600.tsr \
  -in example.com-20260923-1600.renewal-1.tsr -token_in \
  -CAfile /etc/ssl/certs/ca-certificates.crt

06Finding things again

Archives

The archive list searches title, address and host 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 or by tag, and sort by newest, oldest, largest, title or site. Tags are listed under each title, and a small seal beside the capture date marks a snapshot that carries a trusted timestamp.

Acting on several at once

Every row in the archive list has a checkbox, and a bar above the table follows your selection. Tick rows one by one, tick the box in the header for the whole page, or click one row and Shift-click another for everything between them. With something ticked you can add a tag or remove a tag on all of it, capture again (one new capture per address, however many of its snapshots you ticked; the earlier snapshots are untouched), or delete. Deleting lists what will go and asks for your password once for the whole selection. Viewers can select rows to compare them but not to change them. A selection covers the page you are on, at most 100 archives at a time.

Comparing two snapshots

The text of any two snapshots can be compared. From a record, Compare with previous opens it against the capture of the same address taken just before, and each row under Other snapshots of this address has a Compare button. From the archive list, tick exactly two rows and choose Compare the two.

The older snapshot is always the "before" and the newer the "after", whichever order you chose. Removed lines are marked with a minus and a red tint, added lines with a plus and a green tint, and inside a line that was edited the words that changed are highlighted. Long stretches that did not change are folded to a single line you can open, and Next and Previous (or the n and p keys) step from one change to the next. The two pickers at the top switch either side to another snapshot of the address and re-run the comparison.

It compares the stored text, so a change to layout, images or scripts does not appear, and a page whose text is the same says so. Snapshots saved before the text view existed have no text and cannot be compared. Each side is compared up to its first 20,000 lines or 2 MB, and the page says when it stopped early.

Sites

Sites groups every snapshot you hold by host, which is the view to use when you want the history of one place rather than one page. Searching inside a site goes further than the list does: it reads the stored text of that site's snapshots and shows you the passage that matched, so you can find a page by something it said rather than by its title.

That scan is bounded — the newest 200 snapshots of the site, within a few seconds — and the page tells you when it did not cover everything rather than implying it did.

Text view

The text rendering 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. Very long snapshots are shown up to 512 KB, with the whole file a download away.

Activity log

The activity log records what happened in the account — captures queued, stored, stopped and deleted, schedules changed, sign-ins — and in a team, which member did it. It is where a question about a missing snapshot gets answered.

Above the log, choose an event type — captures, schedules, team, and for the owner, sign-ins and billing — and a From and To date, then select Apply. Both dates are inclusive and use the same time zone as the timestamps in the table. Clear returns to the full log.

The search box on the log narrows it as you type to the events that contain every word you enter — an event name like archive.deleted, an address, a team member, a date. It searches the most recent 200 events shown on the page, in your browser. Press Esc to clear it.

07Scheduled captures

A schedule captures on its own, and comes in two kinds. A page schedule captures its own address, one snapshot 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.

Hours are read in the schedule's own time zone, chosen by name. A day of the month past the end of a short month is clamped to its last day, so a schedule set for the 31st still fires in February. A schedule lands on the same wall-clock time every period rather than drifting, and one that could not run does not owe the runs it missed — it resumes at its next occurrence. Editing a schedule moves its next run to the first time the new rule matches.

Schedules can be paused, run once on demand, edited or deleted at any time.

Sitemap runs

Both sitemaps.org document types are understood: a urlset listing pages, and a sitemapindex pointing at further sitemaps, which is followed one level down. The gzipped form is decompressed transparently, detected by content rather than by file extension. Every address a sitemap names gets the same screening a manual capture gets, before it is fetched or queued.

08Teams

A workspace is your account: its archives, schedules, storage and plan. On the paid plan you can invite other people into it from Team. Each person signs in with their own account, password and second step, so nobody shares a login and every action in the activity log names who took it.

An invitation is a link sent by email. It works for seven days, only for the address it was sent to, and can be withdrawn before it is used. Someone without an account creates one with that address and lands back on the invitation. The owner can change a member’s role or remove them at any time, and a member can leave.

Anyone who belongs to more than one workspace switches between them from the top of the sidebar, and a band above every page says whose workspace you are in. What a member captures is stored in the owner’s workspace and counts towards its storage. Members keep their own alerts: the person who started a capture is told when it lands.

09Getting your data out

A snapshot taken here is not trapped here. Four of the five stored files are yours to take at any time, from the record page.

Document

One .html file. Open it in any browser, on any machine, with no network at all.

Text

The plain-text rendering, for quoting, grepping and diffing one capture against the next.

WARC

ISO 28500, WARC 1.1. Opens in pywb, replays through ReplayWeb.page, and satisfies an institution that accepts nothing else. One download carries the document, the text and the preview together.

Manifest

metadata.json — a digest and a size for every stored file, plus the addresses, times, viewport and tool versions. An inventory or an integrity check can be answered from it without opening the snapshot.

Timestamp

The RFC 3161 token as a .tsr file, for checking with OpenSSL against the downloaded document, plus any renewals and the revocation lists kept with them. See Trusted timestamps.

Export account in Settings takes everything at once: one .tar.zst with a folder per capture holding its files, its timestamp token and any renewals, and a manifest that also lists each record’s tags and note, along with the OpenSSL command for every link in its timestamp chain.

The WARC states plainly what it can and cannot claim: the response headers in it are reconstructed, because capture drives a browser and returns one document with its subresources already inlined — the individual HTTP exchanges that built the page are never observed. The container says so in its own metadata rather than leaving a later reader to assume a crawler produced it.

10Storage and deletion

Each account has a snapshot storage allowance, 100 MB by default. Usage counts every file a capture stores, since all of them occupy the bucket, and your current usage is on the dashboard rather than buried in a settings page. In a team, everything members capture counts towards the owner’s workspace.

• Queuing is refused up front when the account is already full — a courtesy, since a page's size is unknown until it has been captured.
• The binding check is immediately before upload. A capture that would cross the line is failed with an explanation and never written.
• Scheduled captures are skipped while an account is over its limit and resume on their own once space is freed. The schedule is not disabled behind your back.

Deleting an archive is the only way to free space, and the only irreversible action in the product: it takes your password again (a team member confirms with their own), is rate limited, and removes every stored file and the timestamp belonging to that snapshot. Deleting one that is still running stops the capture first. Need more room? Allowances are set per account — write to us.

Two larger versions of the same action are in Settings. Erase stored data empties the account — every snapshot, every schedule, every alert — and keeps the account itself, your address, your password and the activity log, so the record of who has been in the account is not quietly erased along with its contents. Close account removes the account outright. Both take your password, closing also takes your address typed out in full, and both then ask for a second confirmation: a six-digit code emailed to your address, or one from your authenticator app (a recovery code also works). A capture still running is stopped before either proceeds.

Erasing happens as soon as you confirm. Closing the account waits 72 hours. When you confirm, we email you the date it will happen and Settings shows it; until then the account works as normal, and Cancel deletion in Settings withdraws the request. If you did not ask for it, cancel it and change your password. After the 72 hours the account and everything in it are deleted and cannot be restored.

Budget alert

On a paid plan, Plan & billing has a Budget alert box. Enter the most you want storage to cost in a month and select Save. If what you hold would cost more than that, we email you once, and not again until the next calendar month. Raising or lowering the limit starts the check afresh. The alert is only a heads-up: nothing is paused, deleted or charged differently. Leave the box empty to turn it off.

11Account and security

Settings shows your storage usage, lets you change your password, choose how you sign in, and lists the sessions currently signed in to the account so you can revoke the ones that are not you. It is also where you erase the account's stored data or close the account altogether. Settings are always your own, whichever workspace you are working in.

Authenticator app

Set up an app shows a QR code for any standard authenticator — 1Password, Google or Microsoft Authenticator, Authy, Bitwarden. Once you enter a code from it, sign-in asks for the app’s code instead of emailing one; the emailed code is not kept as a fallback, because that would make the account only as strong as the mailbox. You get ten single-use recovery codes, shown once, for when the phone is out of reach. You can make a new set, which cancels the old one, or turn the app off, and both take your password.

Passkeys

A passkey lives on your phone, computer or security key and signs you in with a fingerprint, face or device PIN: no password, no code. It is bound to dashboard.archivepanel.com, so a look-alike site cannot use it. Add one from Settings, name it after the device, and choose Sign in with a passkey on the sign-in page. You can hold up to ten, and removing one takes your password. Adding or removing a passkey, and every change to the authenticator app, is announced in your notifications.

Contacting support

Contact support, at the foot of the sidebar and of every page, opens a short form: pick what it is about, write what happened, and send. The reply comes to the address you sign in with, and the message says which account and workspace it came from, so there is no need to explain that. Anyone in a workspace can write in, viewers included.

The security page covers the threat model in full — what the capturer will and will not fetch, and what an archived page is allowed to do when you open it. What we store, how long, and the rights you have over it are in the Privacy Policy.

12Limits and defaults

Everything in one table. These are the defaults on the hosted service; the per-account allowance is the one that moves.

Anything not covered here: use Contact support in the dashboard, or write to support@archivepanel.com.