What Happened to Pocket? The Complete Story of the Read-It-Later App

On May 22, 2025, Mozilla announced that Pocket would die in forty-seven days. Nate Weiner, the man who had started the product in 2007 and spent nearly a decade running it before selling it to Mozilla, did not accept the premise that its opportunity had disappeared. In a public reaction collected by Techmeme, he argued that finding and spending time with worthwhile material had become harder, while the technology for understanding that material had become dramatically better. He saw a failure of vision, not a problem that had stopped mattering.

Eighteen years earlier, Weiner had been a web designer in Minneapolis who was still learning to program. He kept emailing himself links to JavaScript tutorials and watching them sink inside his inbox. As he later recalled in a long-form interview about Pocket’s origin, one night he built a Firefox extension, roughly 160 lines of code and “two gigantic, ugly buttons.” One saved the page. The other opened a reading list.

That tiny tool became Read It Later, then Pocket. It reached millions of people, traveled inside hundreds of other products, and became Mozilla’s first acquisition. On July 8, 2025, it shut down anyway.

Every bookmark is a small wager on a future self.

You find an essay between meetings, a recipe while standing in a grocery store, or an idea at midnight that deserves more attention than you can give it. You press a button and make a quiet promise: later. For nearly eighteen years, Pocket was where millions of those promises went.

The familiar explanation is that products come and go. True, but not very useful. Pocket was not merely software people used. It held years of unrealized intentions: reporting they meant to revisit, instructions they might need again, writing that changed them, and links whose original pages had already disappeared.

Pocket’s rise explains why saving the web became a habit. Its end exposes the unfinished work hidden inside that habit. Capturing a link is easy. Returning to it is harder. Keeping it when the company disappears is harder still.

This is the complete story of Pocket—from one developer’s overnight Firefox extension to a product used by millions, from Mozilla’s first acquisition to a contested shutdown—and what its history teaches anyone building the next place for the things worth keeping.

What Pocket was

Pocket was a read-it-later service. That sounds obvious now because the behavior has been absorbed into browsers, reading apps, social feeds, note-taking tools, and operating systems. In the late 2000s, it was a sharper idea: discovery and reading did not have to happen at the same time.

You could encounter an article on a desktop computer, save it, and read a cleaner version later on a phone or tablet. The service synchronized your list across devices. Its reader removed most page furniture. Mobile apps made saved stories available offline. Tags and search helped people recover an item without remembering which folder they had put it in. Text-to-speech turned a reading queue into something closer to a personal podcast feed. Recommendations gave people another path into the web beyond whatever a social network happened to place in front of them.

The word Pocket described the experience unusually well. The product was not a formal archive, a public profile, or a publishing tool. It was the digital equivalent of folding a clipping and carrying it with you. The important thing was not organizing the clipping at the moment you found it. The important thing was getting it out of your way without losing it.

That distinction made the product feel lighter than traditional bookmarking. A browser bookmark often implied permanence and taxonomy: choose a folder, name it correctly, perhaps never see it again. Pocket offered a single, forgiving action. Save now. Decide what it means later.

People used it for long-form journalism, recipes, travel research, technical documentation, essays, videos, and all the small fragments of the internet that arrive at the wrong moment. Publishers added Pocket buttons. Other apps integrated its API. E-readers made it part of their reading flow. By the time the service closed, the concept felt less like an app feature than a piece of internet plumbing.

That was the achievement. Pocket did not invent the human desire to keep something for later. It built one of the cleanest rituals around it.

Read It Later: the tab that could wait

Pocket’s first name was almost aggressively literal: Read It Later.

Nate Weiner created it in 2007 as a Firefox extension. The original need was modest and personal. At the web design firm where he worked, he was trying to teach himself more JavaScript. Email was his improvised reading list, and it was a bad one. The tutorials he sent himself became mixed with every other obligation and disappeared before he returned to them.

The overnight prototype replaced those emails with two actions: save this page, and show me what I saved. Early versions used Firefox’s bookmark system underneath, but presented the result as a queue rather than another folder hierarchy. Weiner sent the extension to a few friends. Someone at Lifehacker found it, wrote about it, and the small tool escaped its original circle.

It is difficult to appreciate how good that idea was without remembering the web around it. Smartphones had not yet become the universal second screen. Responsive design was not a default. Many publishers treated mobile pages as cramped afterthoughts. RSS readers organized subscriptions, but they did not solve the random article discovered through a link, email, forum, or search result. Browser bookmarks were dependable, but they were more filing cabinet than reading room.

Read It Later separated finding from using. That small separation was the product. It also gave Weiner an unusually clear signal: strangers had the same annoyance strongly enough to install a tool made by someone they did not know.

The project remained a side project while he kept doing contract work. In early 2008 he added synchronization and an article view. In 2009 he built an iPhone application and charged $4.99 for it. The income soon suggested that Read It Later might support more than an evening experiment. He stopped treating it as an accessory to his work and began treating it as the work.

For years, much of the company was still one person. Weiner built the website, API, iPhone and iPad applications, and handled customer support before a conventional team existed. The First Round history of Pocket says he remained the only employee for roughly half of the company’s first eight years. That matters because the early Pocket story was not a committee discovering a market category. It was one person following the same unresolved irritation from device to device until the product around it became a company.

There is a useful product lesson in that origin. Read It Later did not begin with a grand theory of knowledge management. It began with a recurring irritation that could be removed in one click. The scope expanded because the underlying behavior kept appearing in new places: first the desktop browser, then phones, then tablets, then third-party apps and e-readers.

The earliest version was not elegant in every dimension. No first version is. But it correctly identified a seam in internet time. The web was becoming better at producing more than a person could consume in one sitting. Read It Later gave the overflow somewhere to go.

By 2012 the service had millions of registered users, paid mobile apps, and hundreds of integrations. It also had a branding problem. “Read It Later” explained the original feature but constrained the future. People were saving video and images as well as articles. The product was becoming less a queue and more a personal staging area for the web.

Becoming Pocket

On April 17, 2012, Read It Later became Pocket. The company also made its previously paid applications free.

The relaunch mattered for more than the new icon. It changed the product’s category in three ways.

First, Pocket was a place, not an instruction. “Read It Later” told you what to do with an article. “Pocket” told you where useful things could live until you needed them. That opened the door to more formats and more reasons for saving.

Second, free apps removed friction at exactly the moment cross-device behavior was becoming central. A read-it-later system becomes dramatically more useful when capture and consumption can happen on different devices. Charging separately at the app-store door made it harder for a new user to experience the complete loop.

Weiner’s account of the decision is revealing. The value of the product was not self-evident in a screenshot or a two-minute trial. People had to build the habit before the service clicked. A free product let more people reach that point. Read It Later had already shown that people would pay for its mobile applications, so the change was not a panicked retreat from a product nobody wanted. It was a bet that the business model should match the longer-lived value of the service.

Third, the relaunch made the experience feel consumer-grade. Pocket organized saved material by article, image, and video. It offered filtering, favorites, tags, and a cleaner visual identity. Contemporary launch coverage reported 4.5 million registered users and integration with more than 300 apps. Those integrations were not decorative distribution. They made Pocket available at the instant of discovery, before a user had time to forget what they meant to save.

The best consumer products make an important action feel smaller. Digital cameras made taking another photograph nearly free. Search engines removed the need to know where information lived. Pocket turned “I should remember to read this” from an open tab and a burden into a button press.

That reduction in friction was Pocket’s growth engine, but it contained a tension that would follow the entire category. When saving becomes nearly free, people save more than they can process. The input side of the system can outgrow the return side. The pocket gets deeper. The bottom becomes harder to find.

At first, that did not look like a flaw. It looked like success.

The product's golden age

Pocket earned affection because it was useful in ordinary moments.

You could save a long article at work and read it on a train with poor reception. You could send several reported pieces to a tablet before a flight. You could catch up through a Kobo instead of sitting in another glowing browser window. You could listen while walking. You could tag material for a project without forcing every item into one rigid folder.

The reading view was especially important. Publishers’ pages were designed for many jobs at once: navigation, advertising, newsletters, video, related stories, analytics, subscription prompts, and the article itself. Pocket could take the part the reader had selected and give it room. The result was not always a perfect capture, particularly on complicated or protected pages, but the intent was clear. Reading was not a side effect of the page. It was the point.

Offline access made the system feel dependable. “Saved” had a practical meaning when the train entered a tunnel. Cross-device sync made the collection feel continuous. A user did not need to remember which machine had first seen the article. Pocket became a small bridge between the web’s abundance and the limited hours in a day.

The Kobo integration shows how far that bridge extended. For years, Kobo readers could connect a Pocket account and read compatible saved articles on an e-ink device. That was not merely a convenience for gadget enthusiasts. It changed the physical context of reading. A story found inside a noisy browser could later appear in an environment built for focus. When Pocket shut down, Kobo retired that integration on July 8, 2025 and later selected Instapaper as its replacement.

Pocket also expanded beyond a private queue. Recommendations and publisher partnerships tried to answer a different question: if the service could see what thoughtful readers chose to keep, could it help other people find worthwhile material? That direction eventually became deeply connected to Firefox through recommended stories and, later, Mozilla’s continuing editorial products.

There was a coherent idea underneath the expansion. The open web had more valuable work than any person could discover alone. Pocket could help at both ends: save the thing you found and surface something you had not.

Not every user wanted both. Some treated Pocket as a focused utility and regarded discovery features as furniture they had not ordered. Others came to value the recommendations as much as the private list. The product had to serve a personal archive, a reading application, a distribution network, and a media-discovery layer without letting any one of them swallow the others.

That is an unusually difficult balancing act. A wrench can be judged by whether it turns the bolt. A reading service is judged by whether people capture, return, trust, enjoy, and sometimes pay—all while the source material belongs to someone else and can change without warning.

Pocket made that complexity look simple. That was part of its magic and, eventually, part of the danger. When infrastructure works quietly, we stop asking what holds it up.

Scale, Premium, and Mozilla

By 2015, Pocket had become a remarkably large product run by a remarkably small company. First Round reported 20 million registered users, two billion saved items, and a team of 20. Registered users are not the same as active users, and cumulative saves are not a measure of reading. Even with those caveats, the figures show how far a one-person extension had traveled.

The business had several possible constituencies. Readers wanted a reliable private utility. Publishers wanted distribution and insight. Platform partners wanted an integration that increased the value of their own products. Investors wanted a business capable of supporting the infrastructure underneath all that saving.

Pocket Premium, introduced in 2014, offered features including a permanent library and full-text search. The product recognized an important distinction: a list of links and a preserved collection are not the same thing. If a source page changed or disappeared, an archived copy could retain what the user had meant to keep. Search across full text could recover an idea even when the title and URL had been forgotten.

Those features moved Pocket closer to an archive, but they also created an enduring dependency. “Permanent” described what the service would retain for a subscriber while the service existed. It did not mean the collection had become independently usable outside Pocket. This is not a trick unique to Pocket. It is the default shape of cloud software. The customer’s object may feel local and personal while remaining operationally attached to somebody else’s servers, policies, and budget.

Mozilla acquired Pocket on February 27, 2017. The deal was notable both for Pocket and for Mozilla: Mozilla described it as its first acquisition and positioned Pocket as a product line alongside Firefox. Terms were not disclosed. The teams had already worked together; Pocket had been integrated into Firefox, and both companies spoke in the language of a healthier, more open web.

Weiner did not describe the sale as cashing out. Pocket’s internal Slack room for discussing the acquisition was called “Rocket Fuel,” and he presented Mozilla as a way to make the product larger, better, and faster. After nine and a half years on the same problem, he told Foundation Capital that the deal was among the best decisions Pocket had made. Read from the other end of the story, that optimism gives the acquisition real stakes. This was supposed to accelerate Pocket, not begin an eight-year countdown.

On paper, the fit made sense. Mozilla had browser distribution, a public-interest mission, and a need to offer useful experiences beyond rendering pages. Pocket had a popular cross-platform consumer product, expertise in article extraction and recommendations, and an enormous map of what people voluntarily saved.

Pocket also began to outgrow its founder. In October 2019, Mozilla promoted Weiner to senior vice president of a new New Markets organization, responsible for expanding a wider product portfolio. Pocket CTO and operations head Matt Koidin took over the product’s day-to-day leadership as vice president and general manager. The service remained inside Weiner’s organization, but it was no longer simply the company he personally ran.

An acquisition also changed the strategic equation. An independent Pocket had to justify itself as a company. A Mozilla-owned Pocket had to justify itself inside a larger portfolio. Those are not the same test. A product can be loved, widely known, and still lose an internal competition for engineering attention.

That sentence is analysis, not a claim about a secret Mozilla spreadsheet. The verified record is narrower: Mozilla acquired Pocket in 2017, operated it for eight more years, and eventually said it would redirect resources toward Firefox. There is no public acquisition price and no responsible basis for inventing one. There is also no evidence that Pocket’s original idea had stopped mattering. The number of replacement guides published after the shutdown makes the opposite case rather loudly.

The problem hiding in the list

The red badge on a reading queue is a peculiar number. In an inbox, zero can mean the work is done. In Pocket, zero might mean you had not found anything interesting. Five hundred might mean you were curious. It might also mean you had constructed a guilt machine.

Saving is emotionally cheap because it converts a present obligation into a future possibility. Reading is expensive because it still requires time. When an app perfects the first action without strengthening the second, the queue can become a warehouse where good intentions go to acquire dust.

This is not a moral failure by users. The products are asymmetric. One tap adds an item; returning requires choosing among hundreds, remembering why something mattered, and having the right amount of attention. The feed outside the library keeps producing fresh temptation while the library inside it grows older and less legible.

Even modern alternatives acknowledge the problem. Readwise describes the traditional read-it-later pattern as one that can get worse as people save more than they can process. Its answer is to bring different reading inputs together and build resurfacing and review into the system. That diagnosis matters because it shifts the job from storage to attention.

Pocket worked on return in several ways: recommendations, listening, tags, search, a clean reading interface, and the simple presence of the queue across devices. Yet the category never discovered a universal cure for the backlog. Some people want a queue that aggressively expires. Some want an archive they can search years later. Some want highlights sent into a note system. Some want a Sunday ritual with no algorithm at all.

The distinction becomes clearer if we separate three jobs:

1. Save the substance. Capture more than an address, and say honestly when capture failed.
2. Make time to return. Help the user choose, read, hear, search, or resurface what they kept.
3. Keep it yours. Let the collection survive a subscription change, acquisition, outage, or shutdown in a form another tool can use.

Pocket was exceptional at making the first click easy. It built meaningful answers for return. Its shutdown showed the limit of the third job.

A hosted export does not prevent a shutdown, but it changes what shutdown means. If the export is complete, documented, and independently readable, a service can disappear without taking the user’s memory with it. If export produces only URLs, the user may inherit a map of buildings that have already been demolished. If export exists but nobody has tested restoration, it is an emergency door painted on a wall.

This is where product language needs to become precise. Sync is not ownership. Offline cache is not an archive. An account export is not portable merely because it downloads. “Permanent” is not permanent if access depends on the original service continuing to authenticate you.

Pocket did provide an export, and Mozilla gave users a final window to request it. That was materially better than closing without a path out. But an export deadline still turned years of personal saving into a time-sensitive administrative task. Miss the email, postpone the download, and “later” could expire.

Why Pocket shut down

Mozilla announced Pocket’s shutdown on May 22, 2025. Its explanation was concise: the way people save and consume content on the web had evolved, and Mozilla would focus its resources on projects that better matched browsing habits and its work around Firefox.

That is the stated reason. Anything more specific needs to be labeled interpretation.

Mozilla did not say that people had stopped wanting to save articles. It did not publish a final active-user count, Pocket profit-and-loss statement, or internal ranking of projects. It did point toward work inside Firefox, including tab groups and enhanced bookmarks, and said Pocket’s recommendation work would continue evolving in the browser. The service closed; parts of the behavior and expertise remained strategically relevant.

The founder’s response made the distinction sharper. Weiner was no longer running Pocket by then. After his period leading New Markets at Mozilla, he returned to a much older interest: music. His current biography describes him as a Minneapolis-based composer and software engineer who completed Berklee College of Music’s Film/TV/Games composition program and now works on screen projects. The person who had spent years connecting readers to stories had changed the medium, but not entirely the preoccupation.

When Mozilla announced the closure, Weiner argued publicly that worthwhile material had become harder—not easier—to find and spend time with, while tools for understanding content had advanced enormously. He regarded the decision as a shortage of vision rather than opportunity. The original post is no longer reliably addressable from the public web, so that reaction is paraphrased here from the contemporaneous Techmeme record, not presented as a direct quotation.

Other operators also disputed the idea that Pocket had nowhere to go. The day after the announcement, Digg founder Kevin Rose publicly offered to take the service over. Medium CEO Tony Stubblebine told TechCrunch that he had explored buying Pocket in 2023 but did not hear back from Mozilla before the shutdown announcement. TechCrunch reported both expressions of interest, but it did not report a formal offer, disclosed terms, or a Mozilla rejection. There is no public evidence that either proposal could have supported Pocket’s users and infrastructure. Their importance is narrower: people outside Mozilla still saw strategic value where Mozilla saw a reason to concentrate elsewhere.

My interpretation is that Pocket faced the classic squeeze of a mature utility inside a larger organization. Its central behavior had become common. Browsers and operating systems could absorb portions of it. More specialized tools could serve researchers, self-hosters, Apple-only users, or bookmark collectors with sharper positioning. Meanwhile, operating a cross-platform capture, parsing, storage, synchronization, discovery, and subscription product remained real work.

Familiarity can make a product look simpler than it is. A read-it-later service must ingest hostile and inconsistent web pages, distinguish article content from navigation, handle changes to publisher markup, manage authentication and paywalls, store personal libraries, synchronize state, support multiple platforms, and respond when the original URL changes. It has to do this while respecting publishers, users, privacy expectations, and the economics of content extraction.

The phrase “just a bookmarking app” is doing the same kind of work as “just land the plane.” The interface may be one button. The obligation begins after the click.

Mozilla’s choice can therefore be understandable without being painless. Organizations have to concentrate resources. Users are still entitled to notice that a product they trusted as a long-term home was, in the end, a line in somebody else’s portfolio.

That tension is not resolved by finding a company with nicer branding. Every cloud service faces incentives, budgets, and mortality. The durable answer is architectural and contractual: make the product valuable while it operates, and make leaving survivable when it does not.

Pocket’s closure was not proof that read-it-later had failed. It was proof that the category’s promise had been larger than its escape hatch.

The shutdown timeline

Pocket did not vanish in a single midnight switch. Mozilla staged the closure, stopped new sign-ups, handled subscriptions and refunds, provided an export period, and later deleted remaining data. The deadline changed along the way, which is why contemporary articles do not all agree.

Date	What happened
May 22, 2025	Mozilla announced that Pocket would shut down, removed the apps from stores, disabled new sign-ups, and stopped new Premium purchases.
July 8, 2025	The Pocket service and apps stopped operating. Existing users could no longer use their libraries normally; the export flow remained available. Kobo’s Pocket integration ended the same day.
October 8, 2025	This was the export deadline in Mozilla’s original announcement. Some news and alternatives pages still report it as the final date.
November 12, 2025	Mozilla’s final support record says exports were disabled on this date. The API was also disabled, and remaining user data was queued for permanent deletion.

The practical conclusion is simple: there is no live Pocket library to log into now. The extension from October to November gave users more time, but it did not create a permanent recovery route.

Subscriptions were addressed according to where and how they had been purchased. Mozilla stopped renewals and explained refunds in its support materials. Pocket Hits, the email newsletter, ended. Recommendation work did not disappear entirely; Mozilla pointed readers toward its continuing recommendation efforts, including Ten Tabs and stories in Firefox.

The authoritative current source is Mozilla’s Pocket shutdown support page. It records the final November date and says the remaining data entered permanent deletion. If you find a guide that promises to connect to a Pocket account or call its API today, the guide is obsolete.

What users actually lost

The export file mattered, but Pocket was more than the rows in it.

Shutdown announcements tend to reduce people to account totals. The reactions to Pocket were more specific. They described commutes, devices, research projects, and habits repeated so often that the software had almost disappeared inside them.

One Hacker News commenter, acjohnson55, said they had used Pocket heavily since the Read It Later era. Annual summaries once put them among the top one percent of users, and most interesting Hacker News stories went straight into Pocket. The subway was where the arrangement made sense: save amid the day’s interruptions, read underground, and arrive with fewer open loops. Their use later declined when they stopped commuting by subway and podcasts took more of their attention. Affection and changing behavior existed in the same account.

Another longtime user, huhkerrf, had signed up in 2011. Pocket was “the first thing I installed on every new browser or phone,” they wrote. By 2025, they were barely saving anything. They still ended their reflection by thanking Weiner and the team. That is a more revealing farewell than uncomplicated outrage: a product can help define a decade of someone’s internet life even after the habit begins to fade.

For Kobo readers, the loss was physical. Pocket could take a page found in a noisy browser and deliver it to an e-ink screen waiting for the evening. Reddit user dachuggs said the integration was part of the reason they bought a Kobo. User hoossy wrote that reading news and long-form work through that format had been wonderful and would be dearly missed. Another, Callo_Arcwing, summarized the dependency in eight words: “Half of what I read on my Kobo.”

The history lived inside collections as well as routines. Chris Huerta started using Pocket in college in 2014 to gather sources for research papers. Looking through the old saves after the shutdown announcement brought back the intellectual trail of that period, not merely a set of addresses. A reading list can accidentally become a diary of questions: what a person was learning, building, worrying about, or hoping to understand.

For people who paid for Pocket’s permanent library, a URL-only export exposed a harsher gap. Hacker News user hiatus examined the export fields and realized the downloaded record did not contain the archived copies. Their conclusion was blunt: “many of the articles in my pocket no longer exist.” A list of destinations is a poor rescue when some of the buildings are gone.

The grief was not universal, and pretending otherwise would make the story less useful. One former user called the announcement a relief because long-running Safari-extension and tagging problems had already pushed them toward a replacement. Another explained that faster, cheaper connectivity had reduced the need for offline reading on planes and trains. Some people had thousands of unread items and treated the shutdown as overdue spring cleaning. These public accounts are illustrations, not polling, but together they show why “browsing habits changed” was both true and incomplete.

Users lost a familiar reading environment. They lost tags whose meaning had accumulated over years. They lost a place where muscle memory already knew how to send an article. People who relied on text-to-speech, offline reading, or Firefox integration had to assemble a new routine from different parts.

They also lost confidence in a category promise. “Save for later” sounds timeless. In practice it meant “save for as long as this particular service and account remain available, unless you export in time.” The legal and technical reality was always closer to the second sentence. The interface encouraged people to feel the first.

We should resist turning every shutdown into theater. A saved article is not a family photograph, and an app is not a public utility simply because we liked it. But personal collections do carry context that raw URLs cannot express. A tag can represent a project. A highlight can record the exact sentence that shifted an opinion. The date an item was saved can reconstruct a line of inquiry. A working captured page can preserve something the live web no longer serves.

What disappeared was not only content. It was arrangement, habit, and the accumulated meaning between items.

That is why migration quality matters. A good migration preserves as much structure as possible and makes gaps visible. It does not pretend that importing a CSV of addresses recreates an old library. A URL can fetch a current page if the page still exists. It cannot guarantee the version the person originally saved, the parsing Pocket produced, or the private reason the item mattered.

Pocket's legacy

Pocket won the most important argument: the moment you discover something is not necessarily the moment you should consume it.

That idea now appears everywhere. Browsers offer reading lists, tab groups, synchronized bookmarks, and reader modes. Bookmarking products archive pages and generate previews. Research tools combine PDFs, newsletters, videos, and highlights. Note systems ingest articles. Self-hosted projects offer private read-it-later servers. E-readers and mobile share sheets make “send this elsewhere” a normal action.

Pocket also helped establish a design vocabulary for calm reading: remove peripheral clutter, preserve typography and images, work offline, and maintain continuity across devices. No single company owns those ideas, but Pocket made them mainstream for a generation of readers.

Its recommendation system represented a second legacy. At a time when discovery increasingly meant an engagement-ranked social feed, Pocket could draw on deliberate saves and human editorial judgment. Mozilla continues to pursue versions of that work in Firefox. Whether every reader wanted recommendations inside Pocket is a separate question. The belief that the open web deserves discovery mechanisms outside the largest social platforms remains valuable.

The shutdown should not flatten that legacy into a warning label. Pocket was not a mistake because it eventually closed. Eighteen years is an extraordinary run for a consumer internet product. Millions of people experienced a better reading workflow because it existed.

The respectful lesson is to keep the interaction and strengthen the promise. Make capture effortless. Make return intentional. Make the exit real.

What replaced Pocket?

There is no universal Pocket replacement because Pocket had quietly become several products at once. The closest substitute depends on which part you actually used.

The comparison below is based on each product’s published features and pricing as checked on September 17, 2026. It is not a hands-on ranking. I have not run a controlled parsing test across all of them, and I will not turn a feature page into a fake laboratory result.

If you primarily want…	Start with	Why	Important tradeoff
A familiar read-it-later service	Instapaper	Cross-platform saving, folders, offline reading, Kobo integration, and a long operating history make it the closest direct substitute.	Advanced search, permanent archive, Kindle delivery, and text-to-speech are Premium features.
A serious reading and highlighting workflow	Readwise Reader	It combines articles, RSS, newsletters, PDFs, EPUBs, videos, and social threads with highlighting and export.	Broader capability brings more complexity and a recurring subscription.
A polished Apple-native reader	GoodLinks	It is built for iPhone, iPad, and Mac, uses iCloud, supports tags, highlights, notes, and Markdown export, and is sold with a one-time purchase model.	It is an Apple ecosystem choice, not a cross-platform service.
Open source and self-hosting	wallabag	It offers an established open-source read-it-later server, apps, offline reading, imports, exports, and an API.	Self-hosting transfers maintenance responsibility to you; hosted service is a separate option.
Rich self-hosted capture and search	Karakeep	It saves links, notes, images, and PDFs, supports full-page archiving, search, automated tagging, RSS, and developer interfaces.	It is closer to a flexible bookmarking and knowledge tool than Pocket’s minimal reading queue.
Broad visual bookmark management	Raindrop.io	Collections, tags, previews, search, integrations, and optional web archives work well for many kinds of links.	Its archived copies are a Pro cloud feature and become inaccessible after a subscription ends before eventual deletion.

Instapaper: the closest direct replacement

Instapaper has shared Pocket’s category for most of its life. Its free service includes unlimited articles and synchronization across web, iOS, and Android. Premium adds full-text search, permanent archive, text-to-speech, Kindle delivery, and other advanced features. Kobo selected Instapaper to replace its former Pocket integration, which makes it the clearest starting point for people whose reading routine centered on a Kobo.

Choose it when you want the old mental model with minimal translation: save an article, read it cleanly later, organize it, and move across devices.

Readwise Reader: the researcher’s version

Readwise Reader treats read-it-later as one input in a larger reading system. It can bring together articles, newsletters, RSS, PDFs, EPUBs, YouTube transcripts, and social threads. Highlighting and downstream export are central rather than secondary. It can import an existing Pocket export and export documents and highlights in usable formats.

Choose it when the value begins after reading—when highlights need to reappear, connect to notes, or feed a research practice. The tradeoff is that a power tool asks more of the person holding it.

GoodLinks: the Apple-native answer

GoodLinks is deliberately narrower. It runs on Apple’s platforms, syncs through iCloud, provides a clean reader, works with tags and search, and supports highlights, notes, and Markdown export. Its one-time-purchase approach will appeal to people who are tired of adding another monthly meter to the wall.

Choose it when your devices are Apple devices and you want the experience to feel native. Do not choose it as the center of a mixed Android, Windows, and web workflow.

wallabag and Karakeep: control with responsibility

wallabag is the established open-source read-it-later option. It can be self-hosted or used through a hosted provider, and it supports imports, exports, offline applications, browser extensions, e-readers, and an API. It is the answer for people who want a recognizable Pocket-like model without making a commercial cloud provider the only custodian.

Karakeep takes a broader approach. It can collect links, notes, images, and PDFs; preserve full pages; support full-text and semantic search; generate tags and summaries; expose an API and command-line tools; and run on your own infrastructure. It is attractive when capture depth and automation matter as much as reading.

Self-hosting is not magic ownership powder. It trades vendor risk for operator responsibility. You now own upgrades, backups, security, storage, monitoring, and the unpleasant discovery that “the server” was a laptop under a desk. That can be an excellent trade. It is still a trade.

Raindrop.io: the wider bookmark manager

Raindrop.io is useful when your collection extends well beyond articles. Its visual organization, collections, tags, previews, and integrations serve designers, researchers, and general bookmark collectors. Pro accounts can keep cloud archive copies of pages.

Read the retention terms carefully. Raindrop’s documentation says archived copies become inaccessible when the Pro subscription expires and are deleted after a grace period. Manual archive downloads are available, but the hosted archive itself remains a subscription-dependent benefit. That may be completely acceptable. The point is to understand the promise you are buying.

How to choose without rebuilding the same trap

Before importing thousands of URLs, answer five questions:

1. What do I save? Mostly articles, or also PDFs, video, newsletters, images, and reference links?
2. Where do I read? Browser, phone, Android tablet, Kobo, Kindle, Apple-only devices, or all of the above?
3. What must be captured? Just the URL, a clean reading copy, the original page, images, highlights, and metadata?
4. How do I get it out? Can I export complete, documented, independently readable files? Can another tool restore them?
5. Who operates it? A commercial service, a platform account such as iCloud, or a server I maintain?

Do not choose entirely from a screenshot. Put ten difficult pages through the workflow you actually use: a normal article, a long article with images, an authenticated page you are allowed to save, a PDF, a page that loads content dynamically, and something already at risk of disappearing. Turn off the network. Search for a sentence rather than a title. Export. Open the result without the service.

That small test will teach you more than fifty “best Pocket alternatives” listicles wearing different affiliate links.

What the next generation must do differently

Pocket’s successor is not one app. It is a standard the category should meet.

1. Save the substance, not only the address

A URL is a pointer, not the thing. Pages change, domains expire, paywalls move, and publishers redesign their systems. A durable library should preserve enough of the chosen material to remain useful, subject to the user’s rights and the publisher’s rules.

It should also expose capture state. “Saved” should not ambiguously mean “we recorded the URL and hope the article parser works later.” Tell the user whether the original source, clean text, images, and metadata were captured. If something failed, say what failed.

2. Design for returning, not hoarding

The library should help a person use what they saved. That may mean a short queue, resurfacing, search by remembered phrase, reading progress, highlights, listening, reminders, or a deliberate review ritual. No single mechanism will fit everyone. The important point is to treat return as a first-class job rather than a happy accident.

A good library may sometimes encourage deletion. Keeping everything forever is storage. Helping a person decide what still matters is product design.

3. Make search reconstruct human memory

People rarely remember exact titles. They remember that the article discussed a surprising aviation analogy, or that it was saved during a particular project, or that a sentence mentioned a city. Full-text search, dates, source domains, tags, notes, and clear metadata help rebuild that partial memory.

AI can help, particularly with semantic retrieval and summaries, but it should not replace a dependable text index or obscure which source produced an answer. A personal library is the wrong place for confident hallucination.

4. Separate cloud convenience from possession

Cloud synchronization is useful. It lets a phone and laptop share state without asking the customer to become a systems administrator. But the cloud copy should not be the only meaningful copy.

Export needs to preserve content and structure in documented formats. The files should open with ordinary tools. A manifest should describe relationships and metadata. Restoration should be tested, not merely promised. Ideally, the product can prove that a collection remains readable when its own backend is unavailable.

5. Publish the exit plan before it is needed

Every service should be able to answer: What happens if I stop paying? What happens if you shut down? How long is data retained? What exactly can I download? Which features disappear with the subscription? Can I move to another tool?

Those answers should not be assembled from three support pages during a crisis. They are part of the product.

6. Earn retention through usefulness

Portable data makes it easier to leave. Good. A service should retain people because the daily experience is excellent, not because their collection has become a hostage with a pleasant typeface.

This is the deeper lesson of Pocket. Trust is not created by suggesting the company will live forever. No company can promise that honestly. Trust is created by making the customer’s future less dependent on that promise.

Pocket taught the web to save for later. Its shutdown taught us that “later” needs an exit plan.

Where Bookmark fits

I am building Bookmark, so I am not neutral about this problem. I can still be precise about what exists.

Today, Bookmark lets you create an account, save and search links in a private library, and open a clean reading view for supported pages. It captures the original HTML and a Markdown reading copy when capture succeeds. You can inspect the source, download an individual Markdown file, or open the original website. A Chrome and Edge extension is available for manual installation before it reaches the store.

Offline access and a complete collection export are still being built. Those are not footnotes. They are required for the ownership promise described in this article. We have work left to do before we can demonstrate that promise end to end.

The goal is straightforward: save the substance, make it easy to return, and leave the door open. Pocket’s history is not marketing material for declaring that mission accomplished. It is a specification for what deserves to be built next.

Pocket FAQ

Is Pocket really gone?

Yes. Mozilla shut down the Pocket service on July 8, 2025. The apps no longer operate, new accounts cannot be created, and the API has been disabled.

Why did Mozilla shut down Pocket?

Mozilla said the way people save and consume content had evolved and that it would focus resources on Firefox and projects better aligned with current browsing habits. Claims about more detailed internal financial or management reasons are speculation unless supported by reporting beyond Mozilla’s public statement.

Can I still log into Pocket or export my old account?

No. The normal service ended in July 2025. Mozilla initially announced October 8, 2025 as the export deadline, then extended availability. Its final support page says exports were disabled on November 12, 2025 and remaining user data was queued for permanent deletion.

What can I do with a Pocket export I already downloaded?

Keep an untouched backup before modifying it. Several replacement products can import Pocket export files, including Readwise Reader and wallabag. Import support varies, so inspect the results for missing tags, duplicates, inaccessible source pages, and articles that were represented only by URLs. The export cannot guarantee that a page still exists on the public web.

What happened to Pocket in Firefox?

The Pocket service closed, so the old save-to-Pocket workflow no longer functions as a personal Pocket library. Mozilla continues to work on saving, organization, and recommendations within Firefox through features such as enhanced bookmarks, tab groups, and recommended stories. Those are Firefox features, not a restored Pocket account.

What replaced Pocket on Kobo?

Kobo ended its Pocket integration when Pocket closed and selected Instapaper as the replacement read-it-later service. Check Kobo’s current device and regional support documentation before choosing a plan or moving a library.

What is the best Pocket alternative?

For the closest conventional replacement, start with Instapaper. For research and highlights across many document types, consider Readwise Reader. For an Apple-native experience, look at GoodLinks. For self-hosting, compare wallabag and Karakeep. For a broad visual bookmark manager, consider Raindrop.io. “Best” depends on devices, capture needs, export requirements, and willingness to maintain software.

Will Pocket come back?

Mozilla has not announced a return of the Pocket service. Parts of its recommendation work and the broader saving problem continue inside Firefox, but the old Pocket accounts, apps, API, and hosted libraries are gone. Treat any future product as a new announcement, not something to wait for when choosing where to keep material now.

Did Pocket fail?

Not in the simple sense. A side project became a category-defining product, reached millions of registered users, influenced browser and reading-app design, and operated for nearly eighteen years. The shutdown shows that a successful cloud product can still end—and that portable, independently usable collections should be designed before the closing notice.

---

Methodology and disclosure: This article was written by Jacques Fu, co-founder of Bookmark. Product features, prices, and shutdown records were checked against linked official sources on September 17, 2026. Alternatives were compared from published documentation, not a controlled hands-on test. Bookmark's current capabilities were checked against the live product; unfinished capabilities are labeled as such.