How to Search Your Twitter Bookmarks Before You Export Them

Exporting a bookmark pile before searching it is like moving boxes before opening them.

You can do it. Sometimes you should. But you will still have the same question after the move:

What was I trying to keep?

Search answers that before the export. It tells you whether you need a quick CSV, a full local backup, or no export at all because the thing you wanted was just one post from one person.

Start with the reason, not the file

Most bookmark searches fall into one of these shapes:

Those are different searches. They should produce different exports.

If the job is one source, you do not need a whole-library backup. If the job is a project, you may want to search first, then export the full library so the project material has a portable home. If the job is “I am worried these bookmarks will disappear,” search is your audit step before the backup.

Native X search is useful, but narrow

X has bookmark search in some surfaces. If it is available in your account, use it for quick retrieval.

But it is narrower than it looks. The keyword search bar at the top of the Bookmarks page is an X Premium feature; on a free account there is no search bar, no filter, and no sort — you can only scroll.¹ And even on Premium it is recent-biased: it filters recent bookmarks reasonably but slows down once you have hundreds saved.¹ There are no operators for author, domain, media type, thread, or age.

Native search also has a simpler limitation: it keeps you inside X. You find the post, then you are back in the feed-shaped place where the bookmark was buried.

It also does not answer export questions:

• Do I have enough full thread context saved?
• Which saved links point to the same domain?
• Which items have media?
• Which saved articles are worth reading offline?
• Which bookmarks have I already started reading?

That is where a local bookmark reader is different. It can search the local library, then export the library as CSV, Markdown, and importable data.

The whole cottage industry of third-party tools — Twillot, xarchive, BookmarQ, Dewey, and others — exists to add exactly this: author filters, real search, and export that native bookmarks lack. The operators below are not a novelty. They are the feature people keep going looking for.

If you want to search before you export, install Totem for Chrome and use the local library as the place where Twitter bookmarks become searchable.

If privacy is the reason you want to search before exporting, be specific about what “private” means. A local-first Chrome extension, a cloud dashboard, and an AI search tool have different data models even when they all call themselves bookmark managers. I keep a job-based comparison here: best Twitter bookmark managers for search, export, and actually reading.

Useful searches before export

These examples use Totem’s search syntax. Plain text works. Quoted phrases work. A handle like @someone works as shorthand for from:someone.

Search by person

from:karpathy

or:

@karpathy

Use this when you remember who posted the thing, but not the exact words.

Before exporting, this tells you whether the author is a real cluster in your library or just one saved post. If it is a cluster, the full export is more useful because the Markdown files keep those posts readable outside the app.

Search by exact phrase

"local first"

Exact phrases are best for quotes, product names, error messages, book titles, or arguments you remember word-for-word.

This is the fastest way to avoid exporting a giant pile when you only needed one source.

Search by domain

site:github.com
site:substack.com
site:developer.chrome.com

Domain search is underrated. It turns a vague memory like “I saved a repo about this” into a small set.

It is especially useful before export because domains often map to use cases:

• site:github.com for code and tools
• site:arxiv.org for papers
• site:substack.com for essays
• site:youtube.com for videos you meant to watch

If the cluster is mostly links, CSV may be enough. If it is mostly essays and threads, Markdown is more useful.

Search by media or link type

has:link
has:image
has:video
filter:thread

These are not just filters. They are export decisions.

has:link usually means you are preserving references. filter:thread means you are preserving reading material. has:image and has:video mean you should remember that most exports preserve URLs and references, not necessarily a full offline media mirror.

Search this before export so you do not misread the resulting ZIP. A bookmark export is usually not the same thing as a complete media archive.

Search by age

older_than:1y
within:30d
since:2026-01-01
until:2025-12-31

Old bookmarks are the ones most likely to need context.

If you search older_than:1y and the results are still meaningful, export sooner rather than later. If you open them and cannot remember why half of them mattered, the problem is not export. The problem is that the save lost its context.

This is the failure mode people describe when they finally open the pile: hundreds or thousands of saves, and no memory of why most of them mattered. That is structural, not a discipline problem. The age search is how you check which end of that you are on before you commit to a file.

Combine searches

from:rauchg site:vercel.com

"service worker" filter:thread

site:github.com OR site:npmjs.com

filter:thread -has:video

The point is not to become a search-operator person. The point is to make the pile smaller before you turn it into files.

What to do with the result

After a useful search, pick the export job:

Totem currently exports the library ZIP, not an arbitrary search-result subset. That is deliberate for the backup path: the importable data layer should represent the library, not a hand-trimmed fragment.

Search is still useful because it tells you what kind of library you are backing up.

Search also tells you whether “full export” is worth it

Totem’s basic export is immediate. It exports what is already local.

Full export takes longer because Totem prepares missing full content first: tweets, threads, and articles where available. That preparation is more valuable when your searches show that the library contains long threads, linked articles, or old project material.

If your searches show mostly short one-off posts, basic export may be enough.

If your searches show saved essays, technical threads, or research trails, full export is worth the wait.

A practical pre-export checklist

Before you click export, run five searches:

filter:thread

has:link

older_than:1y

from:someone-you-save-often

"the project or topic you care about"

You are not trying to organize the whole library. You are trying to understand what kind of material it contains.

Then export with the right expectation:

• CSV for inventory
• Markdown for reading
• JSONL plus manifest for restore
• full export when context matters

The hidden benefit

Search changes the emotional shape of export.

Without search, export feels like panic: “Get everything out before I lose it.”

That panic is not hypothetical. Pocket — Mozilla’s read-later app — shut down on July 8, 2025, with data export disabled and deletion beginning November 12, 2025.² A saved pile can simply stop existing. That is the fear that turns “back up my bookmarks” into a 2 a.m. emergency.

With search, export becomes calmer: “I know what is here. I know what I care about. Now I want a local copy.”

That is the better order.

Search first. Export second. Read eventually.

For the method comparison, read how to export your X / Twitter bookmarks. For what the ZIP actually contains, read what gets exported when you export Twitter bookmarks.