SReader Reading Notes
Where to Move Your Saved Articles After Pocket's Shutdown
Your Pocket export holds links, not articles. Here is what survived, three replacement paths, and six steps to a local library no shutdown can touch.
If you are staring at a CSV of URLs exported from a service you trusted, wondering what is actually recoverable, this guide is for you. Pocket's shutdown orphaned millions of saved articles, and what disappeared was more than an app. Reading positions are gone. Tag context survives only as columns in a spreadsheet. Any article you saved that exists nowhere except as a link now depends entirely on whether the original page is still online.
This is a migration guide, not a eulogy. It answers three questions: what did your export actually contain, where should your library live now, and how do you keep this from happening again. One note for anyone who arrived here by searching for a "Pocket alternative": most lists point to another account-based app with the exact same structural flaw that just cost you your library. The comparison below is more honest than that.
A pattern, not a fluke
Start with the verified timeline. Mozilla announced Pocket's shutdown on May 22, 2025. The app and browser extension stopped working on July 8, 2025, the same day annual Premium subscribers began receiving automatic prorated refunds. The export window was originally set to close on October 8, 2025, then extended twice, first to November 6 and finally to November 12. After that date, all Pocket user data was permanently deleted.
Pocket was not an outlier. Omnivore, a popular open-source read-later service, shut down on November 15, 2024, two weeks after its team was acqui-hired by ElevenLabs on November 1. All Omnivore user data was deleted. Instapaper, one of the oldest names in the category, was acquired by Pinterest in 2016 and later spun back out. Even the services that survive tend to change hands.
The reason is structural. Hosting millions of personal libraries on central servers, forever, is not a business model that holds up. Acqui-hires, pricing changes, and shutdowns are not accidents that occasionally befall account-based services; they are built into the category. The user cost is concrete every time: a deadline, confusion about what the export contains, and data that disappears with no appeal process.
What your Pocket shutdown export actually contains
The export mechanics were simple. You logged in at getpocket.com/export, clicked "Export HTML file," and waited up to 24 hours for the finished file to arrive by email at the address connected to your Pocket account.
What you received depended on your account type. Free accounts got a CSV, commonly named part_000000.csv, with five fields: title, url, time_added, tags, and status. Archived items were included. Premium exports also included an HTML bookmark file, ril_export.html, and highlights arrived separately as pocket_highlights.csv, which required its own import.
The gap is the part to internalize. Pocket's own export documentation was blunt: "The export does not contain the complete article text. It also does not preserve your reading position." Your export is a list of pointers and metadata, not a library of articles.
The window is now closed. No fresh downloads have been possible since November 12, 2025, so if you requested an export, search your email archives for it. That file is the only copy that will ever exist. Back it up before doing anything else.
A clean import does not mean the article survived
This is why so many Pocket imports disappoint. Pocket built its reader view by fetching the original page again at view time; the full text of an article was never stored on its servers. When you import a list of URLs into a new app, that app has to fetch each page itself. Pages that have died, moved behind a paywall, or changed address do not come back.
"A successful import only proves that the bookmark moved. It does not prove that the original page still exists." That line, from dEssence's guide to the Pocket export file, is the correct mental model for any migration tool that reports a clean import.
So audit before you trust. Spot-check a sample of your oldest URLs, since link rot compounds with age. For pages that are gone, the Wayback Machine can often recover the text, and when it does, save what you recover as a file so it cannot vanish a second time.
The deeper issue is a destination problem. A local file captures the article text itself. A URL captures a promise that someone else's server will keep a page online. Only one of those survives a shutdown.
Your three Pocket alternative paths
Cloud sync, bookmarks, or local files. Each lane has real options, and each charges you something different.
Path 1: cloud sync services. Instapaper and Readwise Reader offer the best sync and the most feature polish. They also require accounts, sync your reading habits to their servers, and recreate the exact shutdown cycle that just cost Pocket users their libraries. Your library lives on infrastructure someone else can turn off.
Path 2: bookmark managers. Raindrop and plain browser bookmarks are strong for organizing URLs and weak for reading. They sort and tag well, but they are not built for sitting down with a long essay. Two Apple-ecosystem options avoid the account dependency entirely: GoodLinks, a one-time purchase around $9.99 that syncs through iCloud with no login required, and DoubleMemory, free to start with no account needed, syncing across Mac and iOS through iCloud with offline reading.
Path 3: local-first readers. Your articles live as files on your device. Offline access works by default, and no service can be shut down underneath you. The open-source readers Foliate and Thorium respect privacy, though with less polish. SReader takes the local-first approach further, adding focal-point reading and adjustable pace control across web articles, EPUBs, and PDFs.
For completeness, there is also the speed-reading archetype, Spreeder and Spritz, which optimizes velocity over comfort. That is a different goal than calm reading.
Cloud sync services | Bookmark managers | Local-first readers | |
|---|---|---|---|
Privacy | Account required; reading habits sync to servers | Varies; some account-free options | Files stay on your device |
Offline access | Depends on caching and sync | Varies by tool | Native, by default |
Reading experience | Polished and feature-rich | Built for organizing, not reading | Varies; SReader adds focal-point reading and pace control |
Formats | Strong for web articles, varies beyond | Links only | Web articles, EPUB, PDF, Markdown, text |
Shutdown risk | Recreates the Pocket cycle | Lower for browser bookmarks, real for account-based tools | Structurally ended |
One point in the cloud lane's favor deserves to be stated plainly: automatic multi-device sync genuinely works well there. That is the real trade. Only you can price it.
Why a read-it-later app without an account ends the shutdown cycle
The cycle has a shape. Save to an account, depend on the service, watch the service shut down, scramble to export before a deadline, then repeat with the next app. Pocket proved that a beloved service backed by a major organization can vanish with a deletion date attached. Omnivore proved it can happen in two weeks.
A read-it-later app without an account ends the cycle structurally rather than by promise. A file on your device cannot be orphaned by a shutdown, a pricing change, or an acquisition. There is no export deadline because there is nothing to export. Nothing you read lives on a server you do not control.
This is risk assessment, not paranoia. You are removing a dependency that has already cost you once. There is a quiet bonus as well: local-only processing means no ads, no accounts, and no data harvesting, so nobody is profiling what you read or how fast you read it.
One honest caveat. If cross-device cloud sync is genuinely essential to your workflow, accepting the account trade is a valid choice. Just know you are accepting it, and know where the exit is.
The migration: six steps to a calm, local reading setup
This is a weekend project, not a research program.
- Locate and back up your export files. Find part_000000.csv, ril_export.html, and pocket_highlights.csv if you have them, and copy them somewhere safe before touching anything else. They are irreplaceable.
- Audit what to keep. Sort by time_added and tags. Most libraries carry a long tail nobody will miss. Keep what you will actually read and let the rest go.
- Spot-check and recover. Test a sample of your oldest URLs. Pull dead pages from the Wayback Machine and save the recovered text. Note the paywalled ones so you can revisit them through a subscription you actually hold.
- Save web articles as local files. For everything worth keeping, capture the article text, not just the URL, so a dead source page can never take the piece with it. We have written separately about reading web articles offline without feeding the algorithm, and the principle is the same: the file is the copy that cannot disappear.
- Consolidate the rest. Bring your EPUBs, PDFs, and Markdown files into the same library, so one place holds everything a Pocket export contained plus the books and documents Pocket never handled.
- Set up your reading workflow. Import the library into a local reader such as SReader and try focal-point reading, one line or word cluster at a time, with adjustable pacing. Dense study material and work documents read differently at a slower setting, and the science behind pace-controlled reading explains why.
The reason this sticks is friction, or the absence of it. An offline reading app opens saved articles instantly on a plane, in a basement, or on a train, with no sync step and no loading. Habits form around tools that never make you wait.
One library, no loading spinners
Day to day, the difference is quiet. Web articles, EPUBs, PDFs, Markdown, and plain text sit in a single library, and everything opens instantly. No loading spinner, no sync waiting, no "reconnecting" banner. The text is simply there.
Focal-point reading changes how long material feels. Reducing the page to one line or word cluster at a time cuts the visual noise that made saved articles heavy, and adjusting the pace keeps dense material readable. If you want the reasoning behind that approach, how focused reading helps you retain what you read covers it.
There is one honest adjustment: no automatic cloud sync. The workaround keeps the files yours. Because your library is just files in a folder, you can sync that folder with any service you already trust, and the files remain yours in standard formats. If that service disappears someday, the files do not.
Pocket is gone. The next account-based reader will eventually go the same way. Local files do not, and the six steps above are how you act on that.
If that is the library you want, Try SReader.