How to search bookmarks by content, not title

Start with the words you still remember

• In Chrome, type @bookmarks in the address bar, press Tab or Space, then try a word from the title or the website name. Check the browser profile where you saved the link.
• If you remember a sentence from the article, choose a tool with full-text indexing and phrase search. Confirm that it has indexed the page before relying on the result.
• If you remember the subject instead, try a short description such as "3D-printed drone camera mount" in a semantic bookmark tool. Open the result to check that it is the page you meant.

What your browser actually searches

A saved bookmark and an archived page are different things. The bookmark points to the page; an archive keeps a copy. Do not assume that saving a bookmark also saves the article text for later search or offline reading.

When a bookmark tool only matches titles and URLs, a search can miss a relevant page. Imagine looking for "drone" when the saved title is "Pavo20 mount, v3 remix" and the address does not contain "drone" either. A full-text index or a useful description gives the search more to work with.

• The title is a snapshot. If the site later renamed the article, your bookmark still carries the old name — and if the tab said "Loading…" when you saved it, that is what got written down.
• A URL can contain an identifier rather than words that describe the page.
• The folder is a decision you made in a hurry, about a search you would make years later.

None of this is a bug. It is what makes bookmarking instant and independent of the network. The cost lands later, and only for people who save a lot.

Why a folder tree stops working at a few hundred links

Folders answer one question well: "where did I file it". That question is only useful if you can remember the answer. At thirty bookmarks you can. At six hundred you are guessing, and the guess is between four folders that could all plausibly hold the thing.

The deeper problem is that filing happens at the wrong moment. You save a link in two seconds while reading something else, and the folder you pick reflects why the page mattered that afternoon. Two years later you want it for a different reason, and you are searching for the reason you have now, not the one you had then.

This is why the usual advice — prune them, nest them, tag them properly, declare bookmark bankruptcy — never sticks. All of it is work done at save time to serve a search you cannot predict.

The four ways round it, and what each one costs

There are four honest approaches, and which is right depends entirely on what you are trying to find.

• A full-text bookmark tool. It indexes text extracted from saved pages. Choose one with phrase search if you remember exact wording. Check what it can read: sign-in pages, unavailable sites and unsupported formats can leave gaps in the index. Raindrop documents full-text search as a Pro feature.
• A web archiver. Tools of the ArchiveBox and Linkwarden kind keep a copy of the whole page, which survives the site going down. That is a different and larger job than search, usually with a server to run.
• A read-later app. Choose this when your main job is returning to an article to read it. Check whether your chosen app searches saved article text or just metadata, and whether it keeps a copy for offline reading.
• Search by meaning. Instead of storing the words, store what the page was about, and match a question against that. This finds a page whose title shares no word with your question — and it will not find an exact phrase, because the phrase was never kept.

These features can overlap in one product. Check its search and archive features separately: a saved copy does not by itself tell you how the search works.

What searching by meaning adds, and where it stops

Searching by meaning reads each saved page once, writes a line saying what it is, and turns that line into a list of numbers that can be compared with the numbers made from your question. Two pieces of text about the same subject land near each other even when they share no words at all. That is how "that 3D-printed part for the drone" finds a bookmark titled "Pavo20 camera mount and antenna holder".

Cross-language results depend on the embedding model you choose. Unbury offers Qwen3 embeddings through OpenRouter for multilingual search; other model choices can return different rankings.

Now the limit, which matters more than the promise. What is kept is a description of the page, not the page. If you are hunting for a specific sentence, a code snippet, a price, or a name that appeared once halfway down an article, a description may omit it. A full-text tool can help if it successfully indexed that part of the page. Choose by which of those two you actually do.

What Unbury reads, keeps and sends

Unbury’s page reader fetches HTML without running JavaScript and limits the text used for a description to 4,000 characters. A refused or unreadable page can fall back to its title and domain. That is why a bookmark can import successfully yet have too little context for a useful result.

The library and vector comparison stay on your Mac. Creating descriptions uses your chosen model provider or configured command-line assistant, and semantic search sends your query to OpenRouter or OpenAI to create its vector. You supply and pay for the required API key. Local storage does not mean offline AI processing.