Is there a limit on X bookmarks?
There is no published cap. There is a practical one, and it is lower than you think.
X does not publish a maximum number of bookmarks, and the save button keeps working well past a thousand. What breaks first is retrieval: the bookmarks timeline stops surfacing your older saves somewhere around the 800 to 1,000 mark, so the posts are still on your account and no longer reachable by scrolling.
That distinction matters, because the two problems have completely different fixes. If you believe you have hit a storage cap you will start deleting things. If you understand that it is a retrieval ceiling, you will get your saves out instead.
What X actually documents
X's own help material covers what bookmarks are, that they are private, and that Premium adds folders. It does not state a maximum. As of this writing there is no announcement, no error message, and no setting anywhere in the product that names a number.
So anyone telling you the limit is exactly 800, or exactly 1,000, is reporting an observation rather than a documented figure. That includes this article. The honest version is: the ceiling is real, it is in that region, and it is a limit on what you can see rather than on what you can save.
What people actually run into
The reports cluster around a few symptoms, and they tend to arrive together once a collection gets large:
- The list stops. You scroll your bookmarks, the spinner turns, and nothing further loads. The saves below that point are still attached to your account; the timeline simply will not paginate past them.
- The page gets slow. Loading the bookmarks tab takes noticeably longer than loading your feed, and slower still on a phone on mobile data.
- Saves appear not to stick. You bookmark a post, the icon fills, and the post is not where you expect it later. Usually it is saved and simply below the visible horizon.
- Search misses things you know are there. On Premium, the bookmark search box can return nothing for a post you are certain you saved, for the same reason.
The developer platform shows the same shape from the other side: the bookmarks endpoint returns the most recent portion of a collection rather than all of it, which is why third-party tools tend to describe their exports in terms of "your recent bookmarks" rather than "all of them".
Why a retrieval ceiling and not a storage cap
A bookmark is a small row: your account, the post, a timestamp. Storing millions of them is not the expensive part. Serving a bookmarks timeline is, because it has to join those rows against posts that may have been edited, deleted, made private, or posted by an account that has since been suspended, and it has to do that fast enough to feel like a feed.
Products in that position almost always bound the read rather than the write. The result is a collection that keeps accepting new entries while quietly becoming a stack you can only see the top of.
How to tell which ceiling you have hit
Two checks, both a minute:
- Bookmark something now, then reload the bookmarks tab. If it is at the top, saving is fine and your problem is retrieval.
- If you are on Premium, search the bookmark list for a phrase from a post you saved a long time ago. If recent saves are findable and old ones are not, that is the horizon.
What to do about it
If you want to keep everything
Get the collection out of X while it is still readable. Bookmarks are not included in the official X data archive, which surprises most people the first time they request one, so an export means a browser extension or a tool that reads the API on your behalf. That is covered in detail in our guide to exporting X bookmarks.
Do this before the collection grows further rather than after. Every export route reaches the same horizon the app does, so the saves that have already fallen below it are the ones you are least likely to recover.
If you want the number to go down
The ceiling is only a problem for a collection that grows without end. A bookmark list that gets worked, where things leave as well as arrive, never approaches it. That is a habit question rather than a tooling question, and it is worth being honest that no app fixes it by itself: something has to make the decisions.
What not to do
There is a "Clear all Bookmarks" option in the overflow menu on the bookmarks page. It does exactly what it says, immediately, with no undo and no export step first. If your collection is large enough that you are reading this article, that button is a way to lose several years of saves in one tap. Export first, every time.
What about likes, lists, and Communities?
People often discover the bookmark ceiling while looking for somewhere else to put things, so it is worth knowing that the neighbouring features behave differently:
- Likes are public by default and have their own very long history, but they are a signal to the algorithm as well as a record for you. Using likes as a save mechanism means telling X to show you more of what you were trying to set aside.
- Lists hold accounts, not posts. They are excellent for reading a subset of people and useless for saving one thing that person said.
- Drafts and DMs to yourself are the classic workarounds. Both work, both are unsearchable in bulk, and both turn into their own pile.
None of these is a bookmark replacement, and reaching for them is usually a sign that the real problem is volume rather than storage.
Does Premium raise it?
Premium adds folders and a search box over the list. Neither is documented as raising any underlying limit, and the reports of the horizon come from Premium and free accounts alike. Folders are genuinely useful for a collection you are actively curating; they are not a fix for a collection that is too large to page through.
If you are hitting this through the API
Developers run into the same wall from the other direction, and the symptoms are clearer there. The bookmarks endpoint is paginated and returns the recent portion of a collection, so a script that walks pages until it runs out does not get everything: it gets everything the endpoint is willing to serve, then stops. Folder endpoints have been reported to cap out at small page sizes as well.
The practical consequence for anyone building on it: do not promise users a complete export. Say "your recent bookmarks", because that is what you can deliver, and a user who discovers the gap themselves will assume your tool lost their data rather than that the platform never handed it over.
The short version
- No published cap on saving.
- A practical ceiling on seeing older saves, in the region of 800 to 1,000.
- Bookmarks are excluded from the official data archive, so export needs a third-party route.
- Never use Clear all Bookmarks before you have an export.