replayweb.page, a web archive viewer that runs in the browser

A viewer with no server, and why that changes the deployment story

ReplayWeb.page is a full web archive viewer that runs directly in the browser, and it is hosted at replayweb.page with the user documentation under replayweb.page/docs. The interesting architectural decision is stated plainly in the README: the repository contains the frontend UI for the replay system, while the backend is provided through a service worker implementation found in the wabac.js project, and both frontend and backend actually run in the browser. The frontend is loaded from ui.js and the backend service or web worker is loaded from sw.js. For a team evaluating this, the consequence is concrete. There is no server process to deploy, no index to build, no per-request rendering pipeline. You serve static files and the archive handling happens in the visitor's browser. The audience is people who have archives and want them readable, and the topics list names the formats involved, warc, wacz, wayback-machine and web-archive, so a WARC or WACZ file is the input you are working with. The project is by Webrecorder, and the app releases are distributed from the Releases page of this repository.

The service worker requirement that constrains where you can host it

There is one hard constraint, and the README states it without hedging: for the backend service worker to work, the static site must be served from either localhost or an HTTPS endpoint. The reason given is browser security, and the note says there is not much that can be done to get around it. So a copy of the built site opened directly from disk will not replay anything, and a deployment on plain HTTP to a hostname other than localhost will fail in the same way. This is a deployment fact rather than a defect, and it is the one to check first when trialling the project, because the symptom appears as a viewer that loads but does not replay. The design also has a nice property: because the service worker is the backend, the archive requests are intercepted in the browser, which is what allows the same static build to be used as a hosted site, as a local server, as an embedded viewer, and as a desktop application without four different code paths. The README points at the user docs for more detail on using the viewer once it is running.

One repository, four deliverables

The repository is a monorepo in the practical sense, and the README lists what is in it. There is the core site hosted on replayweb.page through GitHub Pages, the documentation site built with Material for MkDocs, the npm module published as replaywebpage, and a build system for both the site and the app. On top of that sits an embedding guide, and the package exports show how little you need to take: the main entry with its type declarations, the Electron sources, index.html for embedding, and a utils entry point. The repository root lists the moving parts: index.html, sw.js and ui.js as the static assets, a mkdocs/ directory for the docs pipeline, scripts/, src/, build/, tests/ and a playwright.config.js for browser tests, plus adblock/ and ruffle/ directories. The package metadata names the product ReplayWeb.page, the version 2.5.3, the licence AGPL-3.0-or-later, and Webrecorder Software as the author. The dependency list is short and telling, with @webrecorder/wabac as the replay engine, lit for the UI elements, bulma for styling, marked and micromark for Markdown rendering, flexsearch for search, and register-service-worker to wire the worker up.

Running it locally with any static HTTP server

The local setup is deliberately undemanding, because the built output is static. Install the Node package dependencies, build the production assets, and serve the repository directory over HTTP:

yarn install
yarn run build
http-server -p 9990

The README notes that a regular HTTP server is all that is needed, and gives python -m http.server 9990 as an alternative to http-server. Once the server is up, loading http://localhost:9990/ gives you the core ReplayWeb.page running locally, with the service worker requirement satisfied because the origin is localhost. The build command produces the two files that matter, sw.js and ui.js. For day to day work, the package scripts give you the variants: yarn start-dev runs the dev mode with the Webpack dev server on port 9990 and autobuilds the dev assets, yarn start-docs builds assets in dev mode and starts the docs, yarn start-prod runs the production site on port 9990 from previously built assets, yarn start-prod-docs builds the production site and serves the docs under the /docs endpoint, and yarn start-electron starts Electron in dev mode. For the docs site, yarn build-docs builds into mkdocs/site and the final static site into mkdocs/_genhtml, which is what CI publishes.

Swapping in a local wabac.js build to test the replay engine

Because the backend lives in a separate repository, the workflow for working on the replay engine itself is to override the generated service worker with a build from your own checkout. The README gives three steps, and the middle one is the one that matters:

yarn build-dev
cp ../dist/sw.js .
http-server -p 9990

You build wabac.js in dev mode in its own checkout, overwrite this repository's sw.js with the copy from that build, and serve the static site with any HTTP server. That swap is the practical reason the two pieces are split across repositories in the first place: you can iterate on the backend without rebuilding the frontend, and you can pin a known-good service worker while you work on the UI. The same split shapes the release model, since the version of the app in this repository carries the wabac dependency as a version range, @webrecorder/wabac at ^2.27.2, so a bug fix in the engine can reach users through a rebuild of this package rather than a change to the site content.

AGPLv3, changelog, and a project that calls itself new

The licence is AGPLv3, and the README says plainly that if you would like to use it under a different licence, or have a question, reach out, because that may be a possibility. That is the single most important commercial fact about the project, and it deserves attention before anything else, since the AGPL has a network use clause that matters for anyone who modifies the viewer and serves it. Without giving legal advice, the practical point is that the terms are not the permissive MIT you get from most web tooling, and the maintainer is open to discussing alternatives. On the project itself, the README asks contributors to open an issue first before submitting a pull request, and gives the reason: this is still a new project and rapidly evolving. The change log lives in CHANGES.md, with release notes on the Releases page, and the recent tags show the pace, v2.5.3 on 2026-09-03 and v2.5.2 with a beta before it on 2026-08-29, while the last push was on 2026-09-03. A CHANGELOG in the repository root, a COPYRIGHT file and a husky directory for git hooks round out the governance picture.

Where replayweb.page is the wrong tool

Three situations rule it out. First, anything that must run from a file system or from plain HTTP on a named host will not work, because the service worker needs localhost or HTTPS, and the README is explicit that this is a browser security requirement with no workaround offered. That is a hard deployment constraint for internal tools on a corporate network with no certificate. Second, a workflow that depends on searching a large archive quickly is not served well by this architecture. The package includes flexsearch, so search is client side, and the README does not document any server-side index, so how a very large WARC behaves in the browser is not something the project commits to. Third, the project asks you to open an issue before contributing, and describes itself as rapidly evolving, which means an embed in a public site is a dependency on a moving target unless you pin a version. On the positive side, the way to use it well is clear: static hosting over HTTPS, an archive in WARC or WACZ form, and the embedding guide for the case where the viewer should live inside a site you already run.

Editorial conclusion

ReplayWeb.page fits archives, universities, newsrooms and anyone who wants to put a WARC or WACZ replay in front of readers without running a replay server, and it fits teams that want to embed the viewer in an existing site through the published npm package. It does not fit a workflow that needs a server-side index, and it does not work when the site is opened from the file system, because the service worker requires localhost or HTTPS. Before deploying, confirm your host serves the site over HTTPS, read the embedding guide at replayweb.page/docs/embedding, and check the AGPLv3 terms, since the README says a different licence may be arranged on request.

Frequently asked questions

Official sources

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