ArchiveWeb.page for interactive, browser-based web archiving

ArchiveWeb.page capture scope and intended users

ArchiveWeb.page addresses a specific limitation of simple page capture: many modern websites depend on network requests, scripts, and user interaction after the initial response arrives. The project presents itself as an interactive, high-fidelity archiving system that runs inside the browser. That makes it relevant to web researchers, archivists, developers examining site behavior, and users who need to revisit a page with more context than a static screenshot or single HTML response provides.

The project is not limited to one runtime. The same TypeScript source supports a Chrome or Chromium extension and a standalone Electron application. The README points users to the Chrome Web Store for the extension and to GitHub Releases for desktop downloads. Developers can instead build either target from the repository.

The recorded collection includes browser network traffic rather than only a rendered page. Based on the architecture in the README, this can include assets requested during interaction. However, the available documentation does not provide a capture-compatibility matrix for individual sites, nor does it promise that every site will replay identically. Sites dependent on unsupported browser features, expiring sessions, external services, or volatile network behavior remain a practical risk.

Capture, IndexedDB storage, and ReplayWeb.page data flow

The extension uses the Chrome debugging protocol to capture and save network traffic. This places collection inside the browser's existing request path instead of relying only on an HTTP fetch performed by an external crawler. The captured data is stored directly in IndexedDB, the browser storage mechanism identified by the README.

Replay is separated from capture. ArchiveWeb.page extends ReplayWeb.page for the replay interface and wabac.js for the service-worker system used in replay and storage. The repository dependencies reinforce that storage is part of a Webrecorder toolchain rather than an isolated local viewer. They include `wabac.js`, `replaywebpage`, `warcio`, IPLD packages, `client-zip`, and `browsertrix-behaviors`. The repository topics also reference WACZ and WARC.

This design has a useful consequence for collection: the archive can be created from a browser that executes the page normally. It also means storage lives in the browser profile. The documentation does not state the IndexedDB quota, retention policy, export controls, or whether private browsing changes persistence behavior. Those details should be checked against the current User Guide or source before treating browser storage as a durable archive service.

Local installation and first ArchiveWeb.page capture

For local development, the README requires Node `>=12` and Yarn Classic `v1`. Clone the repository, enter its directory, install dependencies, and create a development build with the documented commands:

git clone https://github.com/webrecorder/archiveweb.page.git
cd archiveweb.page
yarn install
yarn build-dev

The resulting extension can be loaded through `chrome://extensions`. In the Chrome Extensions page, choose `Load Unpacked Extension` and select the `./dist/ext` directory. Click the extension icon to open its popup, then use the popup to start archiving. The README does not document a command-line recording workflow, so the extension popup is the first supported interaction described for a local capture.

For a packaged desktop build instead, the documented command is:

yarn run pack

The platform-specific output is placed in `./dist/`. The README does not enumerate the filenames produced for each operating system, so an adopter should inspect that directory after packaging rather than assume a particular binary name.

Extension development versus the standalone Electron path

The extension and Electron app share source code, but their development loops differ. For the Chromium extension, the README provides a watch command:

yarn run start-ext

Saving source changes recompiles `./dist/ext`. The extension still needs to be reloaded from `chrome://extensions` after the rebuild. This extra browser step is friction, but it gives extension developers direct feedback in the same Chromium environment used by the extension.

The Electron development path starts the desktop application directly:

yarn run start-electron

It opens recording in a new window and is described as supporting Flash and IPFS sharing. Its source files do not rebuild automatically after changes. The developer must rerun `yarn run build-dev` and then `yarn run start-electron`.

The packaged Chrome Web Store extension and a downloaded desktop release are the practical alternatives to building from source. They remove the local build loop, but the README gives no command for comparing their feature sets. The choice therefore turns on whether browser-native operation, local development, or a desktop window matters more.

ArchiveWeb.page linkage changes and release maintenance

Developers who need to test a local `wabac.js` can link it into the project. The documented setup starts in the `wabac.js` repository, where Yarn creates a local link:

yarn link

ArchiveWeb.page then consumes that linked package:

yarn link "@webrecorder/wabac"

Returning to the release build requires disconnecting the link and forcing dependency reinstallation:

yarn unlink
yarn install --force

That workflow is explicit, but it adds a dependency-resolution step and makes the checkout less predictable if the link is left in place. There is no documented rollback command for application or extension releases in the README.

The repository is not archived. Its last push was on 2026-09-04, and releases include `v0.17.1` on 2026-09-04, `v0.17.0` on 2026-08-30, and `v0.17.0-beta.0` on 2026-08-29. These dates show recent project activity, but the README does not state a long-term support window or a compatibility policy for older archived content. Upgrading also means reassessing the browser, Electron, `wabac.js`, ReplayWeb.page, and storage format versions used by an existing collection.

AGPL-3.0-or-later obligations and archive portability limits

The `package.json` identifies the project license as `AGPL-3.0-or-later`, matching the repository description. That designation matters when an organization modifies or distributes the software, but the project files do not explain how the license applies to a particular deployment or archived web content. Organizations seeking compliance guidance need to review the license text with their own legal process rather than treating this article as legal advice.

There is also a boundary between code licensing and archive portability. The README says archives are stored in IndexedDB, while the package dependencies include components associated with WACZ and WARC workflows. It does not state which export format the extension button exposes, how to move an IndexedDB archive between profiles, or whether every archive can be transferred without the application. Users who need long-term custody should confirm export, import, checksum, and replay documentation before relying on browser storage alone.

The Electron application is not a replacement for a server-side archive system. It still records through browser behavior, and its extra window does not add a documented server scheduler, distributed crawler, retention policy, or administrative backup service. Those requirements need another system or a separately confirmed workflow.

What ArchiveWeb.page does not document

The documentation is clear about the two delivery forms and the main technical dependencies, but it leaves several operational questions unanswered. It does not document supported browser versions beyond the Chrome or Chromium requirement, background recording limits, request-size limits, handling of failed subresources, or expected behavior when IndexedDB storage is full. Those omissions make small validation captures more important than assuming every workflow is covered.

The documentation also does not provide a formal migration or rollback procedure. Recent releases indicate versioned software, but no release notes are included here that explain whether archives created by one version can be replayed by another. It does not list site categories known to fail, nor does it define whether cookies, authenticated sessions, media streams, or cross-origin resources are included in every capture.

For evaluation, the relevant test is therefore not just whether a page appears in the archive view. Check whether styles, scripts, images, user-triggered requests, and the interaction sequence needed for the task are retained. Then close and reopen the stored archive, test it in a clean browser session if the workflow permits, and record any dependency on the original account or live service. Those checks expose limits that the project overview itself does not enumerate.

Editorial conclusion

ArchiveWeb.page fits browser-based collection and interactive replay, particularly for developers working with Webrecorder's WACZ, WARC, IndexedDB, and replay components. It does not suit users who need a server-side crawler, documented rollback procedures, or an application outside Chrome and Chromium. Verify capture coverage on the sites that matter, browser storage capacity, expected archive portability, and your obligations under AGPL-3.0-or-later before adopting it. For a first decision, load the extension from the Chrome Web Store, record one interaction-heavy page, close and reopen the archive, and confirm that the required requests and interactions survive replay.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. webrecorder/archiveweb.page on GitHub