The X bookmark limit, explained

The X (Twitter) bookmark limit is really two different numbers, and most articles blur them together. The X API returns at most your 800 most recent bookmarks; that's a hard cap, documented by X and confirmed by X staff. The X app itself has no published bookmark limit at all: the Help Center doesn't list one, and X's own accounts have said you can save as many posts as you want. Yet users keep hitting walls in practice. Here's what's confirmed, what's folklore, and what to do about it.

The confirmed number: 800, through the API

X's developer documentation for the bookmarks lookup endpoint states that the GET method returns 800 of your most recent bookmarked posts. When a developer asked on the official forums why older saves never appear, X staff confirmed that only the most recent 800 bookmarks are available through the API.

That single number shapes the whole third-party ecosystem. Every app that reads bookmarks through the official API, Bookmarx included, sees a sliding window of your latest 800 saves and nothing older. It's not a rate limit you can wait out or a tier you can pay past. Save number 801 pushes save number one out of the window, permanently, as far as the API is concerned.

A concrete version, because the sliding part is what people miss: suppose you have 750 bookmarks and connect an API-based tool today. It can see all 750. Bookmark a hundred more posts over the next month without the tool syncing, and the window now ends at save 51; the first fifty are gone from its view. Tools that sync continuously stay ahead of the window. One-shot API exports race it.

What X says about the app: no cap

Inside the product, the story is different. X's Help Center pages on bookmarks mention no maximum. X's own account has described bookmarks as a place to collect your favorite posts and sort them into folders, with no number attached, and Grok, answering as X's assistant, has told users there's no official limit on how many they can save.

So officially: save away. The storage side appears to be effectively unbounded, and the Twillot team has claimed accounts with over 200,000 saves still on record. Storage isn't the problem. Retrieval is.

What users actually see

This is where the conflicting answers come from. Plenty of people scroll their bookmarks page and find it stops feeding them posts somewhere in the high hundreds. ContextBolt's testing describes a wall around 800 to 1,000 in the web view, where the list quietly stops loading older saves.

Developer forum threads from 2025 and 2026 report pagination that ends early or loops. Other users, meanwhile, report scrolling far past 1,000 without trouble.

My honest read: the display behavior is inconsistent and undocumented, and it varies by client, list size, and whatever X's infrastructure is doing that week. Anyone who tells you the app has one exact display number is guessing. The API's 800 is the only number with a source you can check.

What actually happens to old bookmarks

Nothing dramatic, as far as anyone can prove. They don't appear to be deleted server side. They fall out of the API window once you pass 800 newer saves, and they get harder to reach in the app as the list grows. Functionally, a bookmark you can't scroll to, can't search for (X's bookmark search bar is a paid feature, which I cover in how to search your X bookmarks), and can't retrieve through the API might as well not exist.

There's a separate, nastier failure mode: the bookmark still exists, but the post behind it doesn't. Authors delete posts, go private, or get suspended, and your saved copy dies with them. That one has nothing to do with limits, and I've covered it in why your X bookmarks disappeared.

What this means for how you use bookmarks

Treat X bookmarks as a stream, not an archive. They're excellent as a capture inbox: one tap, private, free. They're a poor permanent library, because the platform gives you no export, no backup, and no guaranteed way back to older saves. Two practical rules follow:

First, if your list matters to you, get a copy outside X. A browser extension reads the page you actually see rather than the API, so it isn't bound by the 800 window; the full walkthrough is in how to export your X bookmarks, and the longer-term setup is in how to back up your X bookmarks.

Second, stop letting saves pile up unread. A bookmark you process within a week never gets anywhere near a limit. Most of the pain in this topic comes from lists that grew for three years untouched.

Where Bookmarx stands on the limit

Bookmarx syncs through the official X API, so it lives inside the same 800 most recent window as every other API-based tool. We don't claim to beat the cap, because nothing using the official API can. What Bookmarx does instead: from the moment you connect, it syncs each new bookmark, keeps its own copy of the content, and summarizes and files it, so your saves stop depending on X's retrieval behavior going forward. Old saves that already left the window stay out of reach, and I'd rather tell you that here than let a landing page imply otherwise.

For the rest of the series, the X bookmark guides hub has the full list.

Frequently asked questions

Is there an official X bookmark limit?

X has not published a cap for the app itself, and X's own accounts have said you can save as many posts as you want. The only documented number is in the developer docs: the API returns at most your 800 most recent bookmarks.

Does X delete my old bookmarks when I pass 800?

There's no evidence X deletes them server side. What's confirmed is that the API stops returning saves beyond the 800 most recent, and many users report the app's list becoming unreliable well before they reach the true bottom.

Does X Premium raise the bookmark limit?

No. Premium adds bookmark folders and a search bar, and X markets no cap on either, but it isn't sold as a way to store or retrieve more bookmarks, and the API's 800 window applies to paid accounts the same way.

How do I protect bookmarks beyond the limit?

Export them with a browser extension, which reads the page you see rather than the API, and keep the file somewhere durable. From then on, sync or export on a schedule so new saves never pile up unprotected.