Stop Losing Saved Articles to Link Rot With Local Archiving

Save web pages offline before link rot takes your saved articles

Somewhere in your read-later list is an article you will never open again. The app still shows the title and the thumbnail. The page behind them is gone.

That is the usual shape of link rot. The domain resolves. The homepage loads. Only your article vanished, removed in a redesign, a CMS migration, or a quiet cleanup nobody announced.

The architecture of cloud read-later tools makes the problem worse rather than solving it. Pocket, Instapaper, and Readwise Reader are cloud-dependent, and they often resolve saved articles against live URLs or remote caches. When the live page changes or disappears, the saved version degrades with it: a paywall reasserts itself, a redesigned layout breaks the stored rendering, and the entry in your list becomes a pointer to nothing. If you are rethinking where your saved articles live, our guide to moving off Pocket covers the export side.

For a list of casual reads, that is an annoyance. For study material, reference articles, and work documents, it is data loss, and it happens silently. Link rot is usually framed as a librarian's problem. For anyone building a personal library of PDFs and EPUBs, it is a preservation problem with your name on it.

The fix is a repeatable local workflow to save web pages offline: pick a durable format, capture the complete page, name the file so you can find it again, read it in a local-first reader, and verify the archive before you depend on it. If you want the reading end of that workflow handled now, Try SReader, a reader that opens EPUB, PDF, Markdown, and text files locally, with no account and no data harvesting.

What actually breaks a saved page

A bookmark is a pointer. So is a link saved to a cloud service. Neither is a copy, and the distinction decides whether you still have the article in five years.

Saved pages break in a handful of familiar ways:

• Dead domains, when a site shuts down entirely
• Site redesigns that delete or relocate old pages
• CMS migrations that change URLs without redirects
• Paywalls that replace the full text you once could read
• Takedowns and removals at the author's or publisher's request

A single page deleted from an otherwise working site is the hardest of these to notice, because nothing looks broken until you tap through. Paywalled scripts and redesigned layouts do the quietest damage to cloud libraries specifically, because the reader re-fetches or re-renders from whatever is live right now.

The working principle is simple: if you did not save the bytes, you did not save the article. A link is a promise. A file is proof.

How to archive web articles permanently: the four formats compared

You have four realistic options, and they are not interchangeable. Ranked by durability, the order runs WARC, single-file HTML, PDF, EPUB.

The strategy that follows from this table: keep a WARC or single-file HTML archive as your master copy, then produce an EPUB or PDF reading copy from it. Preservation and consumption are different jobs. The master guarantees survival. The reading copy guarantees comfort. Conflating them is why people default to PDF for everything and end up with archives that cannot reflow to a phone screen.

PDF's trade-off is real. It is universal and layout-accurate, which matters for academic papers and anything where the visual arrangement carries meaning. But the text will not reflow to your screen or preferred font size, so a two-column PDF on a phone stays a two-column PDF on a phone. EPUB is the opposite: the calmest reading experience of the four, with adjustable pace and typography, but the least faithful visual snapshot of the original page.

The single-file HTML archive: one file, any browser

For most readers, single-file HTML is the durability-to-effort sweet spot. The archive is one file, viewable in any browser, with no extension installed and no JavaScript running, decades from now. Because the file contains the page text, plain or formatted, your operating system's desktop search can index and find it. Images and other resources are inlined into the file itself, which eliminates the broken-image problem that kills folder-of-files saves, where the HTML survives but the asset directory does not.

The reference tool here is SingleFile. Its own format comparison lays out these advantages directly, along with extras that fit an archiving habit: auto-save of tabs, annotation before saving, and optional upload destinations including Google Drive and GitHub (SingleFile). The annotation step is worth using, because notes you make before saving travel inside the file rather than living in an app database that may not survive the next migration.

You will see two variants: .html and .mhtml. Both inline images into a single file. Choose .html when maximum browser compatibility matters, which for a long-term archive is most of the time.

WARC and WACZ: the archivist-grade master copy

WARC is the format web archivists trust, and it is worth understanding even if you never open one. As Webrecorder puts it, "every time an archiving program downloads a file from the web it adds it as a record to the WARC file, along with additional header information like where it was downloaded from and at what time" (Webrecorder). WARC is an ISO-standard open format, ISO 28500, which means it is documented independently of any vendor that might disappear.

WACZ, developed by Webrecorder in 2021, packages WARC files in a ZIP-style container with extra indexing metadata for faster replay. The longevity signal is strong: the Library of Congress acknowledged WACZ as a sustainable digital format as of May 2024.

The practical appeal for a personal library is twofold. First, a WARC captures the entire page plus its resources and metadata, not just the text you happened to select. Second, the record headers preserve provenance: where the page was captured from and when, information that survives long after the live page dies. ArchiveWeb.page, also from Webrecorder, lets you capture interactive pages, including JavaScript-heavy ones, directly into WARC or WACZ from your browser.

Use this tier for the pages you genuinely cannot afford to lose. Everything else can live as single-file HTML.

Capturing the complete article: keep images, footnotes, and layout intact

Capture is the highest-risk step in the whole workflow, and it is where most saved-article failures originate. Three culprits account for nearly all of them: lazy-loaded images that only appear as you scroll, print stylesheets that strip content the browser considers decorative, and paywalled scripts that swap the article body for a stub when the page is saved rather than read.

A pre-flight routine catches all three:

1. Open the article in reader mode or print mode first, so the body renders as static text before you save.
2. Scroll to the bottom of the live page to force lazy-loaded images to load.
3. Disable JavaScript-dependent widgets before capturing, so nothing essential depends on scripts that will not run later.
4. Count the images: compare what you see on the live page against what landed in the saved file.
5. Annotate before saving where your tool supports it, marking sections or sources you will want later.

Treat capture completeness as its own step. Do not close the tab until the saved file matches the live page. A text-only husk with empty image placeholders is not an archive.

A naming scheme that survives every app migration

Filenames outlast databases. Every library app you have used in the past decade is either gone or restructured, and database-driven exports from services like Pocket and Instapaper often do not survive the trip. A plain filename does.

Use this convention: YYYY-MM-DD Author - Title [source-domain], as in "2026-01-14 Anderson - The Economics of Attention [example.com]". It sorts chronologically by default, and it is searchable by name, author, and source. Including the source domain preserves provenance, so you always know where an article came from even after the page dies and the link stops resolving to anything.

Keep folders flat, one folder per topic, rather than building deep nested trees that demand maintenance. If your archive grows large, maintain a single index.md that acts as a searchable catalog of the whole collection. Keyword-rich names mean desktop search and your reader app both surface the right file instantly. The scheme is app-independent by design: it works with any current or future local-first reader, because it relies on nothing but the file system.

Save web pages offline, then read them calmly

Getting the archive is half the workflow. The other half is reading it somewhere designed for focus rather than feeds.

SReader natively opens EPUB, PDF, Markdown, and plain text files, all processed locally: no ads, no accounts, no data harvesting, and reading progress that never leaves your device. The honest gap is that single-file HTML and WARC, the superior preservation formats, are not reading formats. They need a conversion step or a companion local reader. Keep both.

Reading copies in SReader get focal-point reading, which means focusing on one line, word, or word cluster at a time instead of a full page of competing text. Pace is adjustable, which matters for long study material and dense work documents where you want to slow down deliberately rather than power through. Your place is kept locally, with no account, no feed, and no sync service logging what you read and when.

The offline reopen test: verify before you need it

Most archiving guides stop at "saved." That word has two meanings, and only one of them is verifiable. Run this check on new captures, and periodically on old ones:

• Open the saved file in a different browser or device than the one used to capture it, ideally with JavaScript disabled, to prove the file is self-contained.
• Confirm every image loads, footnotes and anchor links work, and the text ends where the original article ended, with no truncated paywall stub.
• Search inside the file for a distinctive phrase from the article. If you can find it, the text is embedded, indexable, and complete.
• Check provenance: the filename date or the WARC record headers should show where and when the page was captured.

Spot-check a handful of archives each month. Decay caught early can be repaired while the live page still exists and can be re-captured. A verified archive is the difference between thinking you saved it and knowing you can read it.

A permanent, private library you actually own

The whole workflow compresses to five moves: capture in a durable format, verify the capture is complete, name the file for search, read it in a local-first reader, and re-test the archive occasionally. None of it depends on a service staying alive, a company keeping its promise, or a URL resolving.

Be honest about what you give up. Cloud tools genuinely make multi-device reading easier, and their highlighting and sync features are real conveniences, trade-offs worth weighing directly. What local archiving buys instead is permanence and privacy: files you own, named so you can find them, verified by hand, and read without an account watching. For a library meant to last decades rather than a news cycle, that is the trade worth making.