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, and deleting is the one move here you cannot take back. If you understand that it is a retrieval ceiling, you will get your saves out instead.
Figure 1. Nothing below the dashed line was deleted. It is still on your account, and the bookmarks timeline will not page down to it, so search cannot match it and no export can reach it. A collection that keeps accepting new entries while becoming a stack you can only see the top of is a limit on reading, not on storing. Schematic. The 800 to 1,000 figure is community-observed rather than published: X documents no cap at all.
What X documents: nothing
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.
The four symptoms, in the order they arrive
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 the read breaks before the write does
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.
Nothing under the line was deleted. It is saved, and it is not served.
Two checks, a minute each
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.
Likes, lists and drafts: three things people try instead
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.
Premium buys folders and a search box, not headroom
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.
The same wall, seen from the API side
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.
None of this is peculiar to X. Every system that has ever offered to keep things for you has bounded the reading before it bounded the writing, for the same reason, and the pattern is old enough to have a history: see The Bookworm and the Bookmark.