What Actually Gets Exported When You Export Twitter Bookmarks?

“Export my bookmarks” sounds like one request.

It is not.

One person wants a CSV. Another wants a backup. Another wants a folder of Markdown files they can read in Obsidian. Another wants to move Chrome installs without losing reading progress.

Those are not the same export. They are different depths of ownership.

The weakest export is a list of links

The smallest possible bookmark export is:

https://x.com/someone/status/123
https://x.com/someone/status/456
https://x.com/someone/status/789

That is better than nothing. It proves you saved a thing. It gives you a way back to X.

It is also fragile.

If the post is deleted, protected, rate-limited, or hard to recognize from the URL alone, the export has very little memory. You still have to open each link to remember why you saved it.

A URL list is an index card. It is not the library.

The next layer is a spreadsheet

Most one-click bookmark exporters aim here. They give you CSV, XLSX, or JSON. A useful CSV usually has one row per bookmark and columns like:

This is the first export that becomes useful outside X. You can filter by author. You can sort old saves. You can search text in a spreadsheet. You can import rows into another database.

This is also where most third-party exporters stop. The open-source tools people reach for — xarchive, prinsss/twitter-web-exporter — output flat rows of tweet text, author, media URLs, quoted tweet, and metrics (xarchive as JSON, prinsss as JSON, CSV, or HTML).¹² That is genuinely useful, and prinsss can even pull bookmarks past the official API’s ~800 cap by reading the web app directly.² But the export unit stays the individual tweet. None of them reassemble a multi-tweet thread into one readable document, so a thread you saved comes back as scattered fragments.

But it still reads like data.

A CSV is good for triage. It is not good for sitting down and reading a thread.

The readable layer is Markdown

Markdown is where an export starts to feel like saved reading instead of saved metadata.

In Totem, the ZIP includes:

• readme.md, an index of the exported bookmarks
• bookmarks/*.md, one Markdown file per bookmark

Each bookmark file is rendered from the same export path as Totem’s reader. If Totem has full detail for that bookmark, the Markdown can include the fuller reading copy: the post, thread context, article text where available, media references, and source metadata.

This matters because Markdown is boring in the useful way.

You can open it in a text editor. You can put it in Obsidian. You can search it with local tools. You can keep it after an app shuts down. You can read it without turning the export into a dashboard.

If CSV is for sorting, Markdown is for reading.

The restore layer is JSONL

The part humans usually ignore is the part that makes restore possible.

In Totem, the importable data lives under data/*.jsonl:

JSONL means “one JSON object per line.” It is not pretty, but it is durable. It can be streamed, inspected, split, and imported without loading one giant JSON object into memory.

Totem’s importer reads these JSONL files only. It ignores CSV and Markdown because those are derived views. The JSONL files are the source of truth for restore.³

This is the difference between “I exported a nice file” and “I can rebuild the library.”

If you want the export to include a readable layer and an importable backup layer, install Totem for Chrome and export from the local library when you need the file.

The manifest is the receipt

A serious export should tell you what it is.

Totem writes a manifest.json file with:

• export format version
• Totem data schema version
• generation time
• app version
• redacted account handle
• hashed account ID
• counts for bookmarks, details, highlights, and reading progress
• paths to each JSONL shard
• SHA-256 checksums for exported files

That sounds technical because it is. It exists so the importer can answer boring but important questions:

• Is this a Totem export?
• Was it created by a newer version I cannot safely import?
• Did any data file get damaged?
• Does this export appear to come from the current X account?
• How many rows should I expect?

The best backup work is invisible when everything goes fine. You only notice it when something goes wrong.

Basic export vs full export

Totem has two export modes because not every bookmark has the same amount of cached content.

Basic export downloads the ZIP from what Totem already has locally. Every bookmark gets a summary row. Bookmarks with cached detail get fuller Markdown and thread/article content.

Full export prepares the missing detail first. Totem walks the local library, fetches missing full content at a conservative pace, marks deleted or protected posts as unavailable, then lets you download a fuller ZIP.

That distinction is important.

If you need a file right now, basic export is the honest answer. If you are making a backup you expect to trust later, full export is the better answer. It takes longer because it is trying to turn more bookmark IDs into readable material.

This is not a Totem quirk. prinsss exposes an explicit “Include all metadata” toggle for the same reason — the full field set “could significantly increase the size of the exported data.”² Light index versus heavy complete dataset is a tension every exporter runs into, not a marketing choice.

What does not get exported

A good export should also say what it does not promise.

Totem export does not include your X password, session cookies, or a Totem server account. Totem does not have a server account system.

It does not replace the official X account archive. If you need your posts, DMs, media uploads, ads data, or account-level history, request the X archive separately.⁴ But the reverse is worth saying plainly: the official archive will not back up your bookmarks. X has no native bookmark export, and the account archive excludes bookmarks entirely — a fact that two separate exporter projects state independently, and the reason those projects exist at all.¹²

It does not magically recover bookmarks Totem never saw. If X only exposes a recent window and Totem did not already capture older items, a later export cannot invent them.

It does not bundle every remote media file as an offline media archive. CSV and Markdown can include media URLs and image references, but the ZIP is primarily a bookmark and reading-data export, not a full media mirror. This holds across tools for a concrete reason: media export is usually a separate ZIP with hard browser-memory ceilings — prinsss notes roughly 2GB in Chrome and 800MB in Firefox.² That is why data exports keep media as URLs rather than embedding the files.

It does not overwrite existing data on import. Totem’s importer is additive: existing rows are counted as already present and skipped.

Match the export to the job

This is why “does it export bookmarks?” is too vague.

Ask the next question:

What should I be able to do with the export tomorrow?

If the answer is “open it in Sheets,” CSV is enough. If the answer is “read through saved threads,” you want Markdown. If the answer is “restore my library on another Chrome install,” you need a real import path.

The deeper the use case, the more the export needs to preserve.

The useful standard

A bookmark export should be judged by four questions:

1. Can I inspect it without the original app?
2. Can I read the saved material without rebuilding context manually?
3. Can I import it back without losing highlights, notes, and progress?
4. Does the file say enough about itself to be trusted later?

Most exports pass the first question. Fewer pass the second. Very few pass the third.

That is the line Totem is trying to draw: not just “get my bookmarks out,” but “keep my reading library portable.”

For the method-by-method comparison, start with how to export your X / Twitter bookmarks. For the field-level spec, the boring version is public at Totem Export Format v1.