Home/Articles/Linkwarden vs Karakeep

Linkwarden vs Karakeep

Two AGPL-licensed, self-hosted bookmark managers that people keep putting head to head. They answer two different questions. Everything below comes from their own docs, repos and pricing pages.

Facts checked against both projects’ own docs and repositories on 2026-09-07. Linkwarden · Karakeep

Two cards side by side, one holding a stack of archived page copies and the other a container of links, notes and images with tags floating above

The short answer

Linkwarden is an archiver that also manages bookmarks. Out of the box it saves a full-page screenshot, a PDF, a single-file HTML copy and a readable text version of every link you add. All four are on by default. Karakeep is an everything-bucket that also saves links. It stores links, plain-text notes and uploaded images or PDFs, runs OCR on images without an AI key, and turns AI auto-tagging on by default.

Almost every other difference follows from those two sentences. Linkwarden needs PostgreSQL and publishes a 4 GB, two-core recommendation. Karakeep runs on SQLite plus a separate headless-Chrome container, and publishes no hardware figure at all. Linkwarden gives you collections that a link belongs to exactly one of; Karakeep gives you nested lists plus smart lists that are saved searches. Karakeep has a CLI, an MCP server and a rule engine, none of which turn up in Linkwarden’s own repos or docs. Linkwarden has a Safari extension, while Karakeep’s Safari story is unclear in its own docs.

If you want one question to settle it, ask whether you care more that a page will still be readable in five years, or that you will be able to find it at all. Linkwarden answers the first. Karakeep answers the second.

Feature by feature

Feature Linkwarden Karakeep
License AGPL-3.0, no commercial restriction AGPL-3.0, no commercial restriction
Database PostgreSQL 16 (required) SQLite (a file in your data directory)
Official docker-compose App, Postgres and Meilisearch (3 containers; Playwright sits inside the app image) App/workers, a separate Chrome container and Meilisearch (3 containers)
Published hardware guidance 4 GB RAM, any 2-core machine, about 1.5 GB image; roughly 350 MB idle since 2.15 None published. A documented minimal install drops Meilisearch, Chrome and AI
Archiving defaults Screenshot, PDF, single-file HTML and readable text all ON. Wayback Machine push is opt-in Screenshot ON (not full-page). PDF, single-file HTML and video download all OFF
Search Meilisearch ships in the free compose: full text over preserved content, plus operators. Without it, falls back to Postgres title/URL/tag matching Meilisearch is required. Without it, search is disabled entirely. Richer query language; semantic and hybrid search added 2026-08, marked experimental
AI Auto-tagging exists since 2.9 but defaults to disabled. Ollama and OpenAI-compatible in the docs; Anthropic, Azure, Perplexity and OpenRouter also ship in code Auto-tagging ON by default; summarization off by default. OCR uses Tesseract and needs no AI key. OpenAI, Ollama, Gemini, OpenRouter, Perplexity, Azure and Cloudflare Workers AI
What you can save Links, plus SingleFile HTML uploads from the extension Links, plain-text notes (markdown, checklists, tables) and uploaded images or PDFs
Organizing Collections (a link lives in exactly one), sub-collections, plus tags Nested lists, smart lists backed by a saved search query, plus tags
Sharing and collaboration Public collection pages. Members get Create, Update and Delete, and read access is always implied. Tags cannot be shared Public read-only list links. Collaborative lists with viewer or editor invites, where each person’s favourites and archive state stay private
RSS Subscribes to feeds hourly, and publishes the 20 newest links of any public collection Subscribes to feeds hourly (up to 1,000), and publishes any list behind a regenerable token. Notes are excluded
Import 5 formats: Linkwarden JSON, Netscape HTML, Pocket CSV, Wallabag JSON, Omnivore ZIP. 10 MB upload cap by default 11 formats in the shipped UI, including Netscape HTML, Pocket, Omnivore, Instapaper, Readwise Reader, OneTab and Linkwarden
Export JSON only (backup.json) JSON or Netscape HTML
Does the export contain your archives? No. The exporter explicitly omits the screenshot, PDF, monolith, readable text and preview No. The export schema carries bookmarks, notes and lists only
Apps and clients iOS, Android, Chromium, Firefox and a Safari extension on the Mac App Store. No official CLI in the project’s own repos iOS, Android, Chrome and Firefox (Safari is ambiguous in their own docs), plus a CLI, an MCP server and a rule engine
API REST, OpenAPI 3.0.2, 42 documented paths, bearer access tokens REST, OpenAPI, bearer API keys with granular scopes since 0.32, cursor pagination
Managed cloud, if you would rather not host $4/month per seat, or $3 billed annually, 30,000 links. No free tier, just a 14-day trial that asks for a card Free tier of 10 bookmarks; Pro $4/month or $40/year for 50,000 bookmarks and 50 GB

Preservation is a question of defaults

Both projects can save a single-file HTML copy of a page, and both shell out to the same Rust tool, monolith. What differs is what happens when you do nothing. In Linkwarden, a fresh install archives every new link four ways: a full-page JPEG screenshot, a PDF, a monolith HTML file and a readable text extraction. In Karakeep, a fresh install takes a screenshot that is not full-page, and leaves PDF capture, full-page HTML archiving and video download switched off.

Both choices are deliberate. Linkwarden is built around link rot, and its own docs describe saving each page in several formats so it stays reachable when the original is gone. Karakeep is built around volume, and its docs say plainly that full-page archives are off because they are large.

The practical consequence is disk. If you are archiving thousands of pages four ways, storage becomes your constraint long before CPU does. Flip Karakeep’s archive settings on and you land in roughly the same place, which is why “Linkwarden preserves and Karakeep doesn’t” is the wrong summary. Linkwarden preserves unless you stop it. Karakeep preserves once you ask it to.

AI: on by default in one, off by default in the other

Karakeep’s auto-tagging is on out of the box. You supply a provider and it tags what you save. Summarization is off by default. Semantic and hybrid search arrived in August 2026, both still labelled experimental in the docs, and both need an embedding provider on top of the tagging one. One detail worth knowing before you commit: embeddings from different models are not compatible, so changing the embedding model means regenerating them for your whole library.

Linkwarden added AI tagging in 2.9 and ships it disabled. Its docs name Ollama and OpenAI-compatible endpoints. The code ships Anthropic, Azure, Perplexity and OpenRouter providers too, which the AI docs page does not currently mention.

The part people get wrong is OCR. Karakeep’s does not need an AI key. It uses Tesseract locally by default, and routing OCR through an LLM is an opt-in flag. If your reason for looking at Karakeep is “I screenshot things and want the text searchable”, you can have that with no API key and no local model at all.

Both apps run perfectly well with no AI configured. In Linkwarden the tagging loop exits at startup. In Karakeep the docs say tagging is disabled and everything else keeps working: crawling, archiving, full-text search, OCR, lists, highlights, RSS and the API.

The tag question nobody answers

Turn on automatic tagging, save a thousand things, and you do not get ten useful tags. You get a long tail of near-synonyms, and tagging falls apart at exactly the scale that made you want it. This is the most common complaint about AI tagging anywhere, so what matters is what each project has actually shipped against it.

Karakeep has moved on this. Version 0.33.1, released on 1 August 2026, describes looking up semantically similar bookmarks when tagging a new one and feeding their existing tags into the prompt as suggestions. That is a direct attempt to make the model reuse your vocabulary instead of inventing more of it. The same release added semantic search, which is no coincidence: the embeddings pay for both.

Linkwarden approaches it from the other end. Its tagging has four modes, and two of them cap the vocabulary by construction instead of by prompt: assign only from tags that already exist, or only from a list you predefine. If a bounded tag set matters more to you than tagging quality, that is a real design difference, and a feature table showing “AI tagging: yes / yes” hides it completely.

What it actually costs you to run

Linkwarden publishes a recommendation: 4 GB of memory, any two-core machine, about 1.5 GB for the image plus your data. Its docs are unusually candid about the trend. The image was around 3 GB and idled near 700 MB before 2.15, and is about 1.5 GB idling near 350 MB after. They also tell you to size for the peak rather than the idle floor, which is the right advice for anything driving a headless browser.

Karakeep publishes no hardware figure at all, so anyone quoting you one is guessing. What you can say from its own files is that the official compose runs three containers with headless Chrome as a separate one, the queue has been SQLite rather than Redis since 0.16, and there is a documented minimal install that drops Meilisearch, Chrome and AI for constrained boxes, at the cost of search being disabled entirely and JavaScript-heavy pages not crawling correctly.

The database choice is the other operational fork. Karakeep on SQLite is a file you can copy. Linkwarden on PostgreSQL is a service you have to back up and upgrade like a service. Neither is harder in absolute terms. They are different kinds of chore.

Getting your data out: the question the comparisons skip

Both projects export, and neither export contains your archives. Linkwarden’s exporter explicitly strips the screenshot, PDF, monolith copy, readable text and preview image from backup.json to keep the payload small. Karakeep’s export schema carries bookmarks, notes and lists, and not the stored assets. So the preservation you chose Linkwarden for is exactly the thing that does not travel in its backup file.

If archive portability matters to you, that changes the shape of your backup plan on both sides: you are backing up the data directory or object store, not the export.

Migration between the two is asymmetric, and it only runs one way. Karakeep ships a Linkwarden importer. Linkwarden does not ship a Karakeep importer. It accepts Linkwarden JSON, Netscape HTML, Pocket CSV, Wallabag JSON and Omnivore ZIP, so coming from Karakeep means exporting Netscape HTML and accepting that your lists and structure do not come with it. If you are genuinely unsure which one you want, that asymmetry is an argument for trying Linkwarden first, because the road out of Karakeep is narrower than the road into it.

One more practical detail: Linkwarden caps imports at 10 MB by default and returns an error above it, which a large Netscape export can exceed.

Where the two projects genuinely diverge

Karakeep is the broader tool. It saves notes and uploaded files as first-class objects, not only links. It has smart lists, a rule engine, webhooks, a CLI, an MCP server, granular API key scopes and offline reading on mobile. Its search query language is richer, with things like is:broken and age:<3m.

Linkwarden is the more focused one, and its collaboration model is more conventional: collections with per-member create, update and delete permissions, public collection pages, and an RSS feed for each. Worth knowing before you plan around it: a link belongs to exactly one collection, tags cannot be shared, and read access is always implied for members even when you assign nothing.

Two smaller asymmetries. Linkwarden has an official Safari extension on the Mac App Store, while Karakeep’s own docs list Safari once as official and once under community extensions, so treat that as unresolved. And Linkwarden’s README puts SSO on self-hosted and Enterprise, not on the standard cloud plan, which is the opposite of what most people assume.

One correction, because it is still being repeated. Older write-ups say Linkwarden has no official mobile apps and that you need a community client. That is out of date. Linkwarden’s own documentation publishes an App Store listing and a Google Play listing, alongside sideloadable builds. Both projects ship first-party iOS and Android apps today, so mobile is no longer a reason to pick one over the other.

If you would rather not run either one

Both sell a managed version. Karakeep Cloud has a real free tier (10 bookmarks and 20 MB, enough to evaluate but not to live in) and Pro at $4 a month or $40 a year for 50,000 bookmarks and 50 GB. Linkwarden Cloud has no free tier: a 14-day trial that asks for a card up front and bills automatically at the end, then $4 per seat per month, or $3 if you pay annually. Its pricing page defaults to the yearly toggle, so it looks like $3 at a glance.

There is also PikaPods, which the Karakeep docs point at as third-party managed hosting at around $3 a month, with a revenue share back to the maintainer.

So which one?

Choose Linkwarden if

  • You are archiving against link rot and want a screenshot, a PDF and a full HTML copy of every page without configuring anything.
  • You want full-text search over the content of saved pages, and you are comfortable running PostgreSQL.
  • You share collections with other people and want ordinary per-member permissions.
  • You use Safari, or you want SSO on a self-hosted instance.
  • You are not sure yet. The import path into Linkwarden is wider than the one out of Karakeep.

Choose Karakeep if

  • You are saving more than links (notes, screenshots and PDFs) and want OCR on images without paying for an API.
  • You want tagging done for you and are willing to plug in an AI provider.
  • You would rather keep a SQLite file than run a Postgres service.
  • You want smart lists, a rule engine, a CLI or an MCP server for automation.
  • You are coming from Instapaper, Readwise Reader, mymind, OneTab, Matter or Linkwarden, and want a one-click import.

And if you conclude you want neither

Plenty of people work through a comparison like this and decide they do not want to run a server for their bookmarks at all. That is a legitimate third answer, and both projects’ own cloud plans are the first place to look, because they fund the open-source work.

Linkflare is the hosted option we build, so treat this paragraph accordingly. It reads both products’ exports directly: Karakeep’s JSON export (avatar, then User Settings, then Import / Export) and Linkwarden’s backup.json (Settings, then Export Data). The limitation is worth stating plainly, because it is the same one both projects have with each other. The import brings your links across and re-fetches them, and tags, lists and collections do not carry over.

Common questions

Is Karakeep the same as Hoarder?

Yes. Hoarder was renamed Karakeep in release 0.23.1 on 5 April 2025. If you are still on the old ghcr.io/hoarder-app/hoarder image you should repoint to ghcr.io/karakeep-app/karakeep, because the project warns the old image may not receive updates.

Which one uses less memory?

Nobody can answer that honestly from published figures. Linkwarden recommends 4 GB and two cores, and says it idles around 350 MB since 2.15. Karakeep publishes no hardware requirement at all. What you can compare is shape: Karakeep runs headless Chrome as a separate container and keeps its queue in SQLite, while Linkwarden bundles Playwright in the app image and needs PostgreSQL alongside it.

Can I move from Karakeep to Linkwarden, or the other way?

Karakeep imports Linkwarden exports directly. Linkwarden has no Karakeep importer, so going that way means exporting Netscape HTML from Karakeep and losing your list structure. Whichever direction you go, the archived screenshots, PDFs and HTML copies do not travel, because neither product includes stored assets in its export.

Do I need an OpenAI key to use Karakeep?

No. Auto-tagging is on by default but simply does not run without a provider, and everything else keeps working: crawling, archiving, full-text search, lists, highlights, RSS and the API. OCR on images uses Tesseract locally and needs no key. You do need Meilisearch, though. Without it, search is disabled completely.

Does Linkwarden work without Meilisearch?

Yes, with a smaller search. Meilisearch is in the official compose file and gives you full-text search across preserved page content plus operators like tag: and before:. Without it, search falls back to PostgreSQL matching on titles, URLs, descriptions and tag names.

Are both really free and open source?

Both are AGPL-3.0 with no added commercial restriction, and both sell a managed cloud on top. Karakeep’s pricing FAQ states there are no feature restrictions in the self-hosted version. Note one inversion on Linkwarden: its README lists SSO for self-hosted and Enterprise users, not for standard cloud subscribers.

What about Linkding?

It comes up constantly alongside these two and it is a fair third option, though it answers a different question again. It is the minimal one, with no archiving pipeline and no AI. This page compares the two tools people actually put head to head.