Every native browser reading list is great for about fifty saves. Then it quietly stops working, and you stop looking at it, and the saves pile up somewhere between a feature you use and a drawer you are scared to open.
This post is about why that happens in Chrome, Safari, and iPhone Safari specifically, and what to do about it without abandoning the save-to-read-later habit.
Where the Chrome reading list actually lives
Chrome's reading list is inside the Side Panel on desktop. Click the star-with-plus icon in the address bar and pick "Add to reading list", or open the Side Panel from the top right and switch to Reading list. Saved items show up as Unread, and you mark them read by hovering and clicking the check.
On Android Chrome it is under the three-dot menu. On iOS the equivalent does not really exist as a separate Reading list tab. Chrome on iPhone does show a "Reading list" entry inside the bookmarks UI, but the workflow is nothing like the desktop Side Panel, and it is not the same thing as Safari's Reading List.
Good at: one-click saving while you are already in Chrome on desktop, a flat list that is fast to scroll, and the Unread state that actually helps you triage.
Breaks at: search that only looks at the page title, nothing that keeps a local copy of the article, no tagging, no notes, no way to get the list out of Chrome in a format you can do anything with. Past a few dozen items the Side Panel becomes a wall of titles you do not remember saving.
Safari's reading list is the most complete one, if you never leave Apple
Safari's Reading List on Mac lives in the sidebar (click the sidebar icon, pick Reading List) and on iPhone it is inside Bookmarks, one of three tabs next to your regular bookmarks and the newer History shelf.
Two things Safari's version gets right that Chrome's does not.
It saves articles offline. On Mac, control-click a Reading List item and pick Save Offline, or enable "Save articles for offline reading automatically" under Safari > Settings > Advanced (Apple documents this in the Safari user guide for Mac). On iPhone, flip "Automatically Save Offline" under Settings > Apps > Safari (from the iPhone user guide). This is the only native reading list that stores a real local copy of the article body, not just a URL.
It syncs across iCloud. Add a page on your Mac, it shows up on your iPhone and iPad within seconds, and the offline-saved article is there too.
Breaks at: search is basic, there is no tagging, there is no way to export your Reading List as a file you can read somewhere else, and the whole system only works if you stay inside Safari. The day you switch phones to Android, or pick up a Chromebook, or decide to try Arc or Zen or Comet, your reading list is locked inside an Apple-only container. And past a few hundred saves, the sidebar starts feeling like a junk drawer with a great synchronisation system.
iPhone Reading List, specifically, and why it degrades
People search "reading list iphone" as its own question, usually because the iPhone version is the one they actually open on the sofa, and it is the one that first feels broken.
Nothing is wrong with it on day one. You hit share, tap Add to Reading List, and the article is there. Sync works. Offline works once you flip the toggle.
What degrades is the second act. You cannot tag a saved article. You cannot add a note. You cannot ask the list "what did I save from The New Yorker this year", because search does not look at the body of the article and it does not understand source filters. And the hardest one: if an article gets paywalled, rewritten, or taken down after you saved it, the offline copy is your only record, and there is no way to get that copy out of Safari and into anywhere else.
If Safari stops being your browser, your Reading List is a souvenir.
Chrome-specific bookmarks hygiene (the other reason people end up here)
"How to organize bookmarks in chrome" is a related search and worth addressing directly, because half the people searching Chrome's reading list got there trying to fix a bookmark problem the reading list does not solve.
Bookmarks and Reading List are different in Chrome. Bookmarks are for pages you want to return to forever. Reading List is for pages you want to return to once. Mixing the two is the most common mistake.
A minimum workable system:
- Bookmark only sites, not articles. "New Yorker home", not "that New Yorker article I want to read tonight".
- Put articles, newsletters, and one-off reads in Reading List or in a read-later tool. Never in bookmarks.
- Keep a small, shallow bookmark folder structure. Four to eight top-level folders, no more than one level deep. More is a maze.
- Every quarter, delete the bookmarks you have not clicked in a year. It sounds precious. You will not miss them.
If you want the one-shot version: paste any article URL into the URL to Markdown converter and you will see the shape a read-later tool pulls out of the page. That is what Chrome's reading list does not give you.
Search that does not read the article is the real limit
The pattern is the same across Chrome, Safari, and iPhone. Save is easy. Finding a specific saved thing six months later is the part that is quietly broken.
None of the native reading lists index the body of the article. They index the title and the URL. That means you can find a saved page if you remember the exact headline, and you can find it if you remember the domain. If you remember the idea ("that piece about why the Nordics do childcare well, I think it was long"), you are scrolling. At a few dozen saves that is fine. At five hundred it is why you stop opening the list.
This is the single biggest reason people move off a native reading list. It is not that the apps are bad. It is that "saved articles you might want to reread" needs search to look at the text inside, and no browser built-in does that.
Pocket was the obvious answer, and then Mozilla pulled it
For about a decade the stock advice was "if the browser reading list isn't enough, use Pocket." That advice stopped being usable in 2025.
Mozilla shut Pocket down on July 8, 2025. Export was available until November 12, 2025, and on that date Mozilla disabled the export and began permanent deletion of user accounts and saved articles. The apps and extensions stopped working the same day. If you still have Pocket installed on your phone, it is a dead icon.
The main reason this post has commercial intent at all is that a lot of people are now redoing a tool decision they thought they had locked in years ago.
What to actually move to
These are the honest options, with what each is best at. No ranking, because the right answer depends on what you want the reading list to become.
Instapaper. Still around, still does the clean-reader-view thing it has always done well. Free tier is generous (unlimited saves, folders, cross-device sync), but full-text search is behind Premium at $5.99 a month or $59.99 a year, and so is permanent article archiving. If you want a Pocket replacement that feels like Pocket felt, Instapaper is the closest.
Readwise Reader. Stronger if you highlight a lot, read across many formats (articles, PDFs, books, YouTube transcripts), and want a daily review queue built in. Readwise's pricing puts Reader inside the "Readwise Full" tier at $9.99 a month billed annually, with a 30-day trial. If your read-later is really a research-and-revisit workflow, Reader is built for it.
Raindrop.io. Bookmarks-first, not reading-first. The free tier is genuinely unlimited (bookmarks, collections, highlights), which is rare. Pro adds full-text search, a web archive, and AI features, priced at roughly $3 a month when billed annually. If your pile is mostly links to reference later rather than long-form articles to read, Raindrop is the right shape.
Keep. Full-text search across the actual body of every article you save. Every save is stored as Markdown in an R2-backed library, which means the content survives the source going down or paywalling later. Exports as Markdown, CSV, or JSON. Connects to your X bookmarks so the tweets and threads you save there sync into the same library. No in-article highlights, no daily review queue yet. Keep is the right answer if you want a searchable archive of the real content, not a list of links pointing back at pages that might or might not still exist.
The native reading list. Genuinely fine if your habit stays small. A hundred Safari Reading List items that sync across your Apple devices and read offline on a plane is a perfectly good setup. You do not need a tool. The problem only starts when the pile outgrows what "scroll and skim" can find.
Pick the one whose shape matches what your reading list actually is. If it is a to-read queue, Instapaper or Reader. If it is a reference library, Raindrop or Keep. If it is a research workflow, Reader. If it is forty links and you are happy, stay.
Once you have a real library, build a loop
Moving off a native reading list fixes the capture problem and the search problem. It does not fix the part where you save things and never look at them again. That is a separate problem, and it is the one covered in the digital commonplace book guide. A resurfacing loop (weekly review, random pull, topic re-read, or an LLM-assisted query against your saves) is what turns a pile into something you actually use.
If half your saves come from X bookmarks rather than articles you open in a browser, there is a companion post on how X bookmarks work and how to get them out. Same underlying problem, different surface.
Plugging the hole
Keep stores the full text of every article you save, searches across every word of it, and exports to Markdown, CSV, or JSON whenever you want to take the library somewhere else. It also auto-imports every bookmark from your X account, so the threads and tweets you save there land in the same library as your articles.