Read-later apps and the unread pile

The read it later button is one of the most successful interface ideas of the modern web. One tap, and an article you cannot read now is stripped of its clutter, reset in decent type, and stored where you will supposedly find it. Every part of that sentence is true except the last word, and the gap between saving and reading — the unread pile — is where this whole category lives.

What they genuinely do well

Credit first, because the engineering is real. Pocket, Instapaper and their heirs solved capture: one tap from any browser or app, and the article is yours. They solved reformatting: the parsers strip navigation, advertising and pop-overs and reflow the text into a clean column, and their typography — measure, leading, type size under your control — often reads better than the source page did. They added sync, offline caching, tagging, highlighting, archiving. Instapaper effectively invented the genre’s look; Readwise Reader extended it into a serious reading environment with feeds, documents and export at its centre.

The differences between the products are real but second-order. Instapaper is the minimalist, still close to its original idea of a quiet grey reading room. Readwise Reader is the maximalist, folding in RSS feeds, PDFs, newsletters and ebooks, with highlighting and export as first-class citizens. Pocket, until its retirement, was the populist, with recommendations and the biggest user base. All of them parse well, format well and sync well. Choosing between them was never the hard part of this category. Reading what they hold is.

None of this is faint praise. The open web is a hostile place to read long text, and this category has done more for on-screen typography than most publishers have. If the job is get this article out of a hostile page and into a readable one, the job is done, and done well, by several products at once. The trouble begins after the save.

The pile

Saving feels like progress. That is not an accusation; it is a description of the psychology the button creates. The tap resolves the discomfort of an open tab — decided, filed, dealt with — while costing nothing, and so the deciding happens at the speed of taps while the reading happens at 200–300 words per minute, when it happens at all. The arithmetic only goes one way. Most heavy users of these apps will recognise the result: hundreds or thousands of items, an archive of past intentions, opened with a faint dread that no typography can fix.

The apps did not cause this, and it would be unfair to claim the pile is anyone’s strategy. But the design does sit asymmetrically: every surface makes saving easier — buttons, extensions, share sheets, email-in addresses — while reading gets a nicer room and no additional force. A pile is what an asymmetry looks like after two years. The honest framing is that these are excellent filing systems attached to an unsolved behavioural problem, and the filing is so good it can disguise the problem for a long time.

There is also a gentler reading of the pile, worth stating fairly: not every save is a commitment. Some saves are bookmarks, some are applause, some are a note to a future self who may never need them. Treating the whole queue as an obligation is a category error that generates guilt nobody needs. The trouble is that the app cannot tell those saves apart — and neither, a month later, can the saver. Which is why the triage below begins by making the distinction explicit.

Saving resolves the tab. Only reading resolves the article.

The asymmetry, stated plainly

What does not shrink a pile

It is worth being clear about the non-solutions, because they are the ones the market keeps offering. A better parser does not shrink a pile; it makes the pile prettier. Text-to-speech genuinely helps some readers get through more — listening while walking is real reading time — but it inherits the same arithmetic once the queue outruns the hours. And summarisation is the tempting one: run the pile through a machine, read the digests, declare bankruptcy with dignity. That can be a rational triage move, but it should be named as triage — a summary of an article is not the article, for reasons set out in summaries are not reading.

What actually shrinks one

Three things shrink piles, and none of them is a feature. The first is triage: deciding, item by item, what deserves reading, what deserves skimming, and what deserves deleting — and letting the delete verdict be respectable. A pile is mostly made of items that were never going to be read; saying so out loud is the single largest reduction available. The second is scheduled time, because reading that happens ‘when there’s a moment’ happens at whatever rate the pile currently demonstrates. The third is a pace — some external pressure that carries you through an article once you have actually started it.

Skimming deserves a word of its own, because the pile makes it respectable. A large share of saved items want ten minutes of your eyes at speed, not thirty at depth — the argument is in the headings and the first sentences, and the rest is elaboration. Deciding an item is for skimming, and then actually skimming it, closes it honestly. It is the middle verdict that keeps triage from feeling like a purge.

1. Once a week, open the queue newest-first and sentence every item: read, skim or delete. Be harsh — in most of these apps the archive quietly keeps whatever you remove, so deletion is rarely as final as it feels.
2. Cap the read list at what one honest week actually contains. For most people that is three to five long articles, not thirty.
3. Give reading a standing slot with a start time, not a vague intention. Twenty minutes on a schedule beats the Saturday that never comes.
4. Read with a pace — a timer, a text-to-speech voice at fixed speed, or a stream. The point is not velocity; the point is that starting commits you to finishing.

Pace is where our own product touches this problem, so weigh what follows accordingly. An RSVP stream is a strong pace: the article moves, at a rate you chose, and the recall check at the end tells you whether the speed was honest. Some readers find this turns a twenty-minute article into a commitment kept rather than a tab reopened. But a stream is a poor tool for the skim pile — it cannot skim — and the triage decisions above matter far more than any delivery mechanism, ours included. A pace serves a plan. It cannot substitute for one.

The exit question

One more thing this category taught everyone recently. Pocket — for years the default of the genre, built into a major browser — was retired by its owner in 2025, and every archive that lived on its servers had to be exported before a deadline. There was nothing improper about the ending: notice was given, an export path provided, products end. But it moved ‘can you leave with your data?’ from a paranoid question to a practical one for every saved-article archive in existence, and it is to the credit of Instapaper and Readwise that export has generally been treated as a right rather than a favour.

The unread pile is not a personal failing, and it is not a software failing either. It is what happens when capture costs a tap and reading costs half an hour, multiplied by the web. The apps in this category deserve better than the mild guilt they have come to evoke — they are good tools holding the overflow of a genuine appetite, and the appetite is the healthy part. The pile shrinks when deciding becomes as deliberate as saving. That is a habit, not a feature, and it is free.