SingleFile: Saving a Whole Web Page as One HTML File

What SingleFile solves, and who it is for

A saved web page is usually not one file. The browser writes an HTML document plus a folder of images, stylesheets and fonts, and the page breaks as soon as that folder moves or a URL changes. SingleFile inlines the resources into the HTML itself, so the result is a single file you can move, email or store without a companion directory. The README describes the project as a Web Extension and a CLI tool that saves a complete web page into a single HTML file.

The audience is narrower than the install list suggests. It fits people who read pages offline, researchers and OSINT practitioners who keep a record of what a page said at a point in time, and anyone who wants a page to survive after the original site changes or disappears. The repository topics include archive, archiver, offline-reading, read-it-later and osint, which is a fair summary of who actually benefits. It does not fit teams that need a full crawl of a site, because it captures one page per action rather than following links.

How the capture works, and what lands in the file

The extension runs inside the page it is saving. The README says you click the SingleFile button in the extension toolbar to save the page, and that clicking again cancels the action while processing. That second click matters: capture is a process, not an instant, and on heavy pages it takes visible time.

What you get depends on the output format you choose. The README's file format comparison table lists two SingleFile outputs, HTML and Self-extracting ZIP, against MHTML, Safari Webarchive and the HTML+folder approach. The table states that HTML output has styles and HTML minified, unused HTML and styles removed, and files viewable without installing any extension or running JavaScript. Binary resources are not encoded in base 64 in the HTML format, and files are not compressed. The Self-extracting ZIP format does the opposite on those two rows: binaries are not base64-encoded and files are compressed, and the table notes that the universal self-extracting format can be viewed without installing an extension.

That table is the most useful part of the README for a decision, because it is honest about trade-offs. Plain HTML is the most portable and the easiest to index, but it has no compression, so pages with large images produce large files. The self-extracting ZIP keeps binaries out of base64 and compresses them, and it can be unzipped to extract page resources, but the table puts a footnote on viewing it without an extension: only when the universal self-extracting file format is used. If your archive pipeline assumes every file opens in any browser, the ZIP path is conditional.

Installing the SingleFile extension and saving your first page

The README gives store links rather than a build-from-source path as the primary install. For Firefox, Firefox for Android, Chrome, Safari on macOS and iOS, and Microsoft Edge, install from the respective store. The Chrome Web Store listing is linked in the README, and the Safari build is distributed through the App Store as SingleFile for Safari.

If you prefer a manual install, the README says you can download the zip of the project and unzip it somewhere on your disk, then follow the temporary-installation instructions for Firefox, or the SingleFile-MV3 and SingleFile-Safari-Extension repositories for Chrome, Edge and Safari. The repository layout includes build.sh, build-extension.sh, rollup.config.js and rollup.config.dev.js, and package.json defines the build and dev scripts:

{
  "scripts": {
    "dev": "npx rollup -c rollup.config.dev.js",
    "build": "./build-extension.sh",
    "test": "node --test"
  },
  "type": "module",
  "dependencies": {
    "single-file-core": "^1.6.5"
  }
}

That block shows the extension is assembled with Rollup and that the capture logic itself lives in a separate package, single-file-core, which the extension depends on. The test script runs the Node test runner. Nothing in the README documents a published npm install for the extension itself, so treat the store and manual zip as the two supported routes.

Once installed, saving is one click. The README's getting-started section is two lines: click the SingleFile button in the extension toolbar to save the page, and click again to cancel. The default save folder is the download folder configured in your browser. The keyboard shortcut is Ctrl+Shift+Y, which the README says saves the current tab or the selected tabs; you can change it under about:addons in Firefox or chrome://extensions/shortcuts in Chrome.

For batch work, the README lists context-menu actions that save the current tab, the selected content, the selected frame, the selected tabs, the unpinned tabs, or all tabs. Auto-save can be activated for the current tab, unpinned tabs or all tabs, and the README states that with auto-save active, pages are saved every time after being loaded, or before being unloaded if not. That behaviour is worth reading twice before enabling it on all tabs, because it turns every page load into a write to your download folder.

Annotations, uploads and where the saved file goes

Saving is not the only action. The README documents an "Annotate and save the page..." context-menu entry that lets you highlight text, add notes and remove content before saving. That is a different product from a plain clipper: it produces an edited copy, and the edits are baked into the file rather than stored separately, so you cannot re-run the annotation later against the original page.

Destinations are configurable. The README says the options page has "Destination > save to Google Drive" and "Destination > upload to GitHub", and that "Misc. > add proof of existence" links the SHA256 of saved pages into the blockchain to prove existence. The blockchain option is unusual and worth flagging as a design choice rather than a default: it means the hash of a page you saved is published somewhere outside your control. The README does not describe how to undo that, and it does not document a rollback path for the upload options either. If you save sensitive internal pages, read the privacy policy in privacy.md before enabling any destination other than the local download folder.

Known limits and the cases where SingleFile is the wrong tool

The README points to a separate known-issues.md file instead of listing limitations inline, and the FAQ is a separate faq.md. That is a documentation split worth knowing about: the main README will not tell you what breaks. The file format table is more candid. HTML output is not compressed and does not contain binaries outside base64, so image-heavy pages produce large files. The self-extracting ZIP can be viewed without an extension only in the universal format, and the MHTML comparison row notes MHTML is viewable without an extension only in Chromium-based browsers and Internet Explorer.

Two structural limits follow from the design. First, capture is per page. SingleFile does not crawl, so a site with fifty pages you want archived is fifty saves unless you drive the CLI. Second, the output is a rendering of the page as captured, not a replay of the site. The README claims files can be viewed without running JavaScript, which is the point, but anything that depended on a live backend, a login session or a script that ran after capture will not be present in the file.

The wrong-tool cases are concrete. If you need a legally defensible, byte-exact capture with HTTP headers and a timestamp chain, a single HTML file is not that artifact. If you need to archive thousands of URLs on a schedule, the extension is the wrong interface and the CLI is the right one. And if your organisation cannot accept AGPL-3.0 obligations, the licence is the blocker regardless of how well the capture works.

SingleFile versus MHTML, Safari Webarchive and save-page tools

The README's comparison table is effectively an argument for SingleFile over three alternatives. MHTML is a single file and can be viewed without an extension, but only in Chromium-based browsers and Internet Explorer, and the table does not credit it with minified HTML or removed unused styles. Safari Webarchive is single-file and viewable only in Safari, and it keeps binaries out of base64. The HTML+folder approach is the baseline: viewable everywhere, unzippable, but not a single file at all.

Against those, SingleFile's HTML output is the most portable option in the table, because it needs no extension and no JavaScript to view. Its self-extracting ZIP format is the option that adds compression and unzippable resources, at the cost of the universal-format caveat. If portability is your priority, the plain HTML format is the one to choose; if file size is your priority, the ZIP format is.

People also compare SingleFile with Monolith and Save Page WE, and those searches are real. Neither tool is described in the README, so the honest comparison is limited to what SingleFile's own table claims about formats rather than about those projects. What can be said is that SingleFile ships both an extension for interactive capture and a separate CLI repository, single-file-cli, for scripted capture, and that the capture engine is factored into single-file-core, which other projects can depend on.

Licence, maintenance and the cost of building from source

The repository is licensed AGPL-3.0, and package.json states the licence as AGPL-3.0-or-later. The AGPL is a copyleft licence with a network clause, and that clause is the part that catches teams: if you modify SingleFile and let users interact with it over a network, the licence's obligations can extend to your modified version. This is not legal advice, and the practical reading depends on whether you redistribute or modify the code. Using the published extension to save pages for your own archive is a different situation from shipping a modified build inside a product.

The dependency single-file-core is separately versioned and pinned in package.json as ^1.6.5, so a build can move when that package does. The last push to the repository was on 2026-09-20, and the releases list shows v1.26.1 on the same date, v1.26.0 on 2026-09-16 and v1.25.0 on 2026-09-15. That is a tight release cadence, which cuts both ways: fixes arrive quickly, and so does churn in a tool you may have scripted against. The README does not document a long-term support branch or a compatibility policy for the options format.

Upgrade cost is mostly the extension updating itself through the store. For a self-built copy, package.json exposes npm run build, which runs build-extension.sh, and npm run dev, which runs Rollup with rollup.config.dev.js. README-BUILD.md exists at the repository root, which is where build instructions live, but its contents are not reproduced here. If you pin a version, pin the single-file-core dependency too, because that is where capture behaviour is implemented.

Editorial conclusion

Adopt SingleFile if you need a portable, offline-readable copy of a page and can live with the AGPL-3.0 licence. Do not adopt it if you need byte-exact fidelity to the live DOM or must keep your integration closed source. Before rolling it out, verify two things on your own pages: that the saved HTML renders correctly with JavaScript disabled, and that the self-extracting ZIP output can be opened by whatever viewer your team uses.

Frequently asked questions

Official sources

1. gildas-lormeau/SingleFile on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases