Last Known Copy

PRACTICE

One Hundred Thousand: the Bookmark Sync Ceiling, and the Years It Went Undocumented

Chrome stops syncing bookmarks at one hundred thousand nodes — a number enforced by default since March 2023, declared in Chromium’s source, absent from Google’s support article as late as a capture of 2025-12-26, and attached to an error state that in one case clears on a thirty-day timer rather than on anything a reader does.

Published 2026-08-06 · Updated — · 2,375 words · 28 sources · Status of facts checked 2026-08-06

The number is 100,000, and until recently the only place this publication could locate it written down was Chromium’s source. As of Chromium’s main branch read on 2026-08-06, components/sync_bookmarks/constants.h contains one declaration and one comment:1

The maximum number of bookmarks that are allowed to be synced. If the number of local bookmarks exceeds this limit, sync will enter a “bookmarks limit exceeded” error state.
inline constexpr size_t kSyncBookmarksLimit = 100000;

The same value is declared a second time, for Android, as int SYNC_BOOKMARKS_LIMIT = 100000 in components/sync/android/…/SyncService.java, with a lint annotation in each file pointing at the other so the two cannot drift apart.2 The figure is maintained deliberately, in two languages, with tooling to keep it consistent.

What the ceiling counts

It does not count bookmarks. It counts nodes.

The check walks the browser’s bookmark tree from the root and increments a counter for every node the sync layer considers syncable; a node is syncable if it is the bookmarks bar, the Other bookmarks folder, the Mobile bookmarks folder, or any descendant of one of those three.3 Three consequences follow, and none is stated in any user-facing text located for this article:

What happens at the ceiling

Chromium defines six distinct error types for this one condition — a fair measure of how many moments the collection is measured at: on sync start, on receiving an update, when nudging for a commit, after an initial merge, and two remote-count cases at initial merge.4 All six reach the same outcome: the bookmarks data type disconnects and reports a model error. Other synced data types are unaffected.

Two details matter to anyone stuck. First, when a tracker already exists, local changes continue to be tracked after the disconnect — the code comment gives the reason as allowing users to delete bookmarks and recover on restart.5 Second, the limit applied to the initial download from the server is deliberately double the standing limit: ExceedsRemoteUpdatesLimit compares the update count against 2 * kSyncBookmarksLimit, with the comment giving the reason as facilitating cleanup by a user who is already over.5 That asymmetry was submitted on 2026-01-29,6 reverted the same day,7 and relanded on 2026-01-30.8 Its change description states the problem it fixes: a user whose server-side collection exceeded the limit could not download it in order to prune it.6

Chromium also records how far over the line each collection is, into a histogram named Sync.BookmarksCountAtLimitExceeded.Local and a .Remote counterpart.5 No published distribution for either histogram was located.

The thirty-day timer

The local-count errors are re-evaluated whenever the count is checked, so deleting nodes and restarting is a live recovery path. One error is different. If the server’s copy was too large at the initial merge, the failure is written into the bookmark metadata as a timestamp, and the same file declares how long it stands:5

kInitialMergeRemoteUpdatesExceededLimitErrorTtl = base::Days(30), with the comment: expiration period for the error state when the initial download of remote bookmarks exceeds the limit; after this period, a new attempt to download all bookmarks is made.

A second constant, kInitialMergeRemoteUpdatesExceededLimitErrorTtlJitter = base::Days(7), is not a variance applied to every client. It is used in one place: migrating clients that recorded the older boolean form of the error are given a random synthetic timestamp between twenty-three and thirty days in the past, so that the whole migrated population does not attempt to re-download on the same day.5 A client that hits the error freshly waits the full thirty days. A client migrated from the old flag waits somewhere between zero and seven.

This is the mechanism behind sync appearing to resume for no reason weeks later. The observable behaviour — nothing changed, then one day it worked — invites a reader to credit whatever they last did to their profile.

The years it went undocumented

The enforcement is not new. The work landed under Chromium bug 1347466 in late 2022: a change submitted 2022-11-02 disabled sync when local bookmark creation crossed the limit, with the stated cause that the merge runs on the browser’s user-interface thread and a large merge freezes it.9 On 2022-11-29 a lower limit of 20,000 was set for iOS and Android; on 2023-03-21 the feature was enabled by default for everyone; on 2023-03-29 the mobile limit was raised back to 100,000.101112 From that last date the number is one hundred thousand on every platform.

What the user saw, for the next two years and seven months, is described by Google’s own change description of 2025-10-22:13

Currently, Chrome imposes a hardcoded limit of 100,000 bookmarks, and users who exceed this limit experience silent sync failures.

That change replaced the hard-coded value with a Finch feature flag so that other values could be trialled; a companion change of 2025-10-28 added a field-trial arm named Limit250k with the parameter sync-bookmarks-limit-value: 250000.14 The study ended on 2026-02-12, the flag and its parameter were deleted, and the default of 100,000 was restored as the plain constant.15 Whatever the experiment measured, the ceiling did not move.

The user-facing error arrived in between. A change submitted 2025-11-20 introduced a kBookmarksLimitExceeded user-actionable error and the surfaces to show it, its description opening with the observation that the data type “fails silently”.16 As of the source read on 2026-08-06, the toolbar avatar button reads Unsaved data and the settings and profile-menu string reads, in full:17

To save bookmarks in your account, delete your unused bookmarks

Neither string contains the number. On Android, the “Learn more” action opens https://support.google.com/chrome?p=manage_bookmarks_android, a p-link declared in SyncSettingsUtils.java; the desktop change left the equivalent link as a to-do.1816 On 2026-08-06 that link resolved to Google Chrome Help article 165139, “Get your bookmarks, passwords, and more on all your devices”, and the article’s Desktop, Android and iOS variants each carried the same two sentences, presented on two of the three as a tip:19

To ensure a smooth Chrome experience, you can save up to 100,000 bookmarks in your Google Account to access them across your devices. If you hit the limit, you can delete unused bookmarks or export them.

So the figure is documented now. Dating that is possible, within a window, from the Internet Archive. Of the captures of that article listed by the Wayback CDX API and fetched on 2026-08-06, the last that preserves the article body without the sentence is 2025-12-26; the earliest that preserves the body with it is 2026-01-31, and the index lists no capture between the two.20 Between those two dates — roughly two years and ten months after the limit was switched on by default — Google published its own number. Whether the sentence appeared on some other Google support page earlier could not be verified.

One instrument was withdrawn on the way. A change submitted 2025-11-17 added a Bookmarks Limit stat to the Local section of chrome://sync-internals;21 the cleanup change of 2026-02-12 removed it again.15 As of the source read on 2026-08-06 that page will name the condition — the string Bookmarks limit exceeded is still defined there — but it will not state the threshold.22

Firefox is a different case, and should not be presented as the same one

Firefox has no equivalent published constant that this publication could locate, and the Firefox bug on this subject is narrower than it looks. Bugzilla 1085128, filed 2014-10-19 under the product Firefox, component Sync, is titled “Initial bookmark sync between desktop and mobile doesn’t work if there are too many bookmarks”; it was resolved WONTFIX on 2014-10-20 and its status is VERIFIED, last changed 2018-09-24.23 The reporter had 6,154 bookmarks. The commenter who resolved it — the account credited on bug 814331 as Richard Newman — put the threshold at 5,000, above which, the comment states, sync runs into “essential limitations on syncing that make the likelihood of problems approach 100%”, and pointed at bug 814331 for the backstory.23

That backstory has a number in it. Bug 814331, “Use info/collection_counts to avoid hitting bookmark limits”, was filed 2012-11-22 under the Bugzilla product Firefox for Android Graveyard, component Android Sync, and is resolved FIXED.24 The code it produced lives in mozilla-services/android-sync, a repository archived on GitHub and last pushed 2015-07-14, where the bookmarks sync stage declares private static final long BOOKMARKS_REQUEST_LIMIT = 5000; // Sanity limit.25

Five thousand, in an archived repository, for a mobile browser that has since been rebuilt. That is not a current Firefox limit and must not be quoted as one. Whether current Firefox enforces any numeric bookmark cap could not be verified.

Counting a collection, without installing anything

As of Chromium’s main branch read 2026-08-06. These steps operate only on a file the reader exports from their own browser.

Chrome’s HTML exporter writes the Netscape bookmark format, opening with <!DOCTYPE NETSCAPE-Bookmark-file-1>, one <DT><A HREF=" per bookmark and one <DT><H3 ADD_DATE=" per folder.26 The exporter also fixes the file’s shape: the bookmarks bar is written as a folder carrying PERSONAL_TOOLBAR_FOLDER="true", while the contents of Other bookmarks and Mobile bookmarks are written one level up, with no folder element of their own, which the source comment attributes to compatibility with the pre-existing file format used by other browsers.26

So, on an exported file:

Two limits on that arithmetic, both read from the cited source files rather than from an export performed here. The first is the two-node correction itself, which matters only within two of the ceiling. The second is larger: the exporter writes local and account bookmark nodes into the same file, while the count the check compares is taken over one tree, so on a signed-in profile holding both, the exported total is the larger number.26 The useful part is the ratio rather than the total: a reader who finds 61,000 bookmarks and 39,000 folders is at the ceiling, and no count of bookmarks alone would show it.

What a collection above the ceiling can do

Stated as rules tied to requirements, not as recommendations.

A collection that must stay in the browser’s own bookmark tree and exceeds the limit needs a sync layer outside the browser vendor’s account. floccus is one documented option in this shape: MPL-2.0, release v5.10.2 published 2026-07-18, repository last pushed 2026-08-05, and its README states it syncs bookmarks via Nextcloud Bookmarks, Linkwarden, KaraKeep, Google Drive, Dropbox, any Git server or any WebDAV-compatible service (retrieved 2026-08-06).27 It is named because it is documented and dated, not because it is endorsed; no limit comparable to Chromium’s was located in its documentation, and that absence is not evidence of absence.

A collection that does not need to be in the bookmark tree at all never meets this limit. A store outside the browser holds records, not nodes in a browser profile. The Ledger carries the licence, release date and export formats for the current tools in that shape, each with its checked date.

Deleting reduces the count; exporting does not. Google’s help sentence offers both, and only the first changes the number the check compares. An export is a copy, and a copy is the thing worth having for a different reason: it is the only part of a browser-held collection that survives the account, the vendor and the device.

Read as a custody term rather than as a bug, one hundred thousand nodes is the point at which a service holding a collection on its owner’s behalf stops holding it. The number was knowable for nearly three years by anyone who read the source; the copy that would have made it irrelevant was always a single file the owner could write to disk. The same argument applies to every link inside that file once the pages behind them begin to go dead.

Where to find it now

The 100,000 figure in Chromium source
Live. components/sync_bookmarks/constants.h, moved into that file on 2026-02-13 from components/sync/base/features.h,28 read on 2026-08-06. The Android mirror is SYNC_BOOKMARKS_LIMIT in components/sync/android/…/SyncService.java.
The Bookmarks Limit stat in chrome://sync-internals
Removed. Added by a change submitted 2025-11-17, deleted 2026-02-12 in the same change that ended the field trial. No export existed; it was a rendered value, not stored data. The error label Bookmarks limit exceeded remains on that page as of the source read 2026-08-06.
The SyncBookmarksLimit Finch feature and its Limit250k arm
Removed from testing/variations/fieldtrial_testing_config.json on 2026-02-12. The arm’s definition survives only in the diff of the change that added it, submitted 2025-10-28, and in the diff of the change that removed it.
Google Chrome Help article 165139, before the figure was added
Wayback captures of the article exist across 2023–2026. Checked on 2026-08-06, the two that bound the window are web.archive.org/web/20251226005725/ (body present, figure absent) and web.archive.org/web/20260131231634/ (body present, figure present); the CDX index lists no capture between them. No export format applies; the page is a live document and the archive is the only record of its earlier state.
Firefox’s 5,000-bookmark sanity limit
Gone from the product; preserved as source. mozilla-services/android-sync is archived on GitHub, last pushed 2015-07-14, and both its master and develop branches still serve the constant, checked 2026-08-06. The Bugzilla record is filed under the product Firefox for Android Graveyard, which is Bugzilla’s own statement of where the code went.

References

  1. The Chromium Authors. “components/sync_bookmarks/constants.h.” Chromium source, refs/heads/main, 2026-02-13. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/sync_bookmarks/constants.h — retrieved 2026-08-06. ↩
  2. The Chromium Authors. “components/sync/android/java/src/org/chromium/components/sync/SyncService.java.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/sync/android/java/src/org/chromium/components/sync/SyncService.java — retrieved 2026-08-06. ↩
  3. The Chromium Authors. “components/sync_bookmarks/bookmark_model_view.cc.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/sync_bookmarks/bookmark_model_view.cc — retrieved 2026-08-06. ↩
  4. The Chromium Authors. “components/sync/service/bookmark_sync_error_state.cc.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/sync/service/bookmark_sync_error_state.cc — retrieved 2026-08-06. ↩
  5. The Chromium Authors. “components/sync_bookmarks/bookmark_data_type_processor.cc.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/sync_bookmarks/bookmark_data_type_processor.cc — retrieved 2026-08-06. ↩
  6. Chromium project. “Increase remote bookmark limit for initial merge (CL 7515948).” Chromium code review, submitted 2026-01-29. https://chromium-review.googlesource.com/c/chromium/src/+/7515948 — retrieved 2026-08-06. ↩
  7. Chromium project. “Revert ‘Increase remote bookmark limit for initial merge’ (CL 7532781).” Chromium code review, submitted 2026-01-29. https://chromium-review.googlesource.com/c/chromium/src/+/7532781 — retrieved 2026-08-06. ↩
  8. Chromium project. “Reland ‘Increase remote bookmark limit for initial merge’ (CL 7531837).” Chromium code review, submitted 2026-01-30. https://chromium-review.googlesource.com/c/chromium/src/+/7531837 — retrieved 2026-08-06. ↩
  9. Chromium project. “[sync] Disable sync if local bookmark creation exceeds limit (CL 3932060).” Chromium code review, submitted 2022-11-02. https://chromium-review.googlesource.com/c/chromium/src/+/3932060 — retrieved 2026-08-06. ↩
  10. Chromium project. “[sync] Set lower synced bookmarks limit for mobile platforms (CL 4061354).” Chromium code review, submitted 2022-11-29. https://chromium-review.googlesource.com/c/chromium/src/+/4061354 — retrieved 2026-08-06. ↩
  11. Chromium project. “[sync] Enable SyncEnforceBookmarksCountLimit feature by default (CL 4356858).” Chromium code review, submitted 2023-03-21. https://chromium-review.googlesource.com/c/chromium/src/+/4356858 — retrieved 2026-08-06. ↩
  12. Chromium project. “[sync] Increase bookmarks sync limit for mobile platforms to 100K (CL 4376757).” Chromium code review, submitted 2023-03-29. https://chromium-review.googlesource.com/c/chromium/src/+/4376757 — retrieved 2026-08-06. ↩
  13. Chromium project. “Add Finch feature flag for bookmark count limit (CL 7074072).” Chromium code review, submitted 2025-10-22. https://chromium-review.googlesource.com/c/chromium/src/+/7074072 — retrieved 2026-08-06. ↩
  14. Chromium project. “Add field trial for bookmark count limit (CL 7087811).” Chromium code review, submitted 2025-10-28. https://chromium-review.googlesource.com/c/chromium/src/+/7087811 — retrieved 2026-08-06. ↩
  15. Chromium project. “Stop SyncBookmarksLimit study and cleanup (CL 7566151).” Chromium code review, submitted 2026-02-12. https://chromium-review.googlesource.com/c/chromium/src/+/7566151 — retrieved 2026-08-06. ↩
  16. Chromium project. “Surface user error when bookmarks limit is exceeded (CL 7054925).” Chromium code review, submitted 2025-11-20. https://chromium-review.googlesource.com/c/chromium/src/+/7054925 — retrieved 2026-08-06. ↩
  17. The Chromium Authors. “chrome/app/settings_strings.grdp and chrome/app/profiles_strings.grdp.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/app/settings_strings.grdp and https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/app/profiles_strings.grdp — retrieved 2026-08-06. ↩
  18. The Chromium Authors. “chrome/android/java/src/org/chromium/chrome/browser/sync/settings/SyncSettingsUtils.java.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/android/java/src/org/chromium/chrome/browser/sync/settings/SyncSettingsUtils.java — retrieved 2026-08-06. ↩
  19. Google. “Get your bookmarks, passwords, and more on all your devices.” Google Chrome Help, article 165139, n.d. https://support.google.com/chrome/answer/165139 — retrieved 2026-08-06. ↩
  20. Internet Archive. “Captures of support.google.com/chrome/answer/165139.” Wayback Machine, 2025-12-26 and 2026-01-31. https://web.archive.org/web/20251226005725/https://support.google.com/chrome/answer/165139 and https://web.archive.org/web/20260131231634/https://support.google.com/chrome/answer/165139 — retrieved 2026-08-06. ↩
  21. Chromium project. “Display the bookmarks limit in chrome://sync-internals (CL 7155641).” Chromium code review, submitted 2025-11-17. https://chromium-review.googlesource.com/c/chromium/src/+/7155641 — retrieved 2026-08-06. ↩
  22. The Chromium Authors. “components/sync/service/sync_internals_util.cc.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/sync/service/sync_internals_util.cc — retrieved 2026-08-06. ↩
  23. Mozilla. “Bug 1085128 — Initial bookmark sync between desktop and mobile doesn’t work if there are too many bookmarks.” Bugzilla@Mozilla, 2014-10-19. https://bugzilla.mozilla.org/show_bug.cgi?id=1085128 — retrieved 2026-08-06. ↩
  24. Mozilla. “Bug 814331 — Use info/collection_counts to avoid hitting bookmark limits.” Bugzilla@Mozilla, 2012-11-22. https://bugzilla.mozilla.org/show_bug.cgi?id=814331 — retrieved 2026-08-06. ↩
  25. Mozilla Services. “AndroidBrowserBookmarksServerSyncStage.java.” mozilla-services/android-sync (archived), 2015-07-14. https://github.com/mozilla-services/android-sync/blob/develop/src/main/java/org/mozilla/gecko/sync/stage/AndroidBrowserBookmarksServerSyncStage.java — retrieved 2026-08-06. ↩
  26. The Chromium Authors. “chrome/browser/bookmarks/bookmark_html_writer.cc.” Chromium source, refs/heads/main, n.d. https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/browser/bookmarks/bookmark_html_writer.cc — retrieved 2026-08-06. ↩
  27. floccus contributors. “floccusaddon/floccus — README and repository metadata.” GitHub, n.d. https://github.com/floccusaddon/floccus — retrieved 2026-08-06. ↩
  28. Chromium project. “Move kSyncBookmarksLimit to a dedicated file (CL 7567783).” Chromium code review, submitted 2026-02-13. https://chromium-review.googlesource.com/c/chromium/src/+/7567783 — retrieved 2026-08-06. ↩

Notes

  1. All Chromium source in this article was read from the refs/heads/main branch on 2026-08-06, when chrome/VERSION on that branch read MAJOR=153 MINOR=0 BUILD=7995 PATCH=0. That branch tip moves many times a day; a reader repeating these reads later will resolve a different commit and may find a different file.
  2. The arithmetic relating an exported file to the sync layer’s node count is derived from the two source files cited — the exporter and the syncable-node test — and not from an export performed for this article. Nothing in this article required anyone to run a browser.
  3. The dating window for the Google support sentence was established by listing the captures of article 165139 through the Wayback CDX API, fetching each, and checking it first for a marker from the rendered article body and then for the figure. The window is therefore bounded by two captures that could have shown the sentence: the later of the two that did not, and the earlier of the two that did.
  4. The venue where this number surfaced publicly for readers rather than for developers is a post to r/DataHoarder dated 2025-01-03 (item 1hsqekk), which reported a Chrome sync-data limit of 100,000 bookmarks reached in practice. Reddit returned a challenge page to an automated request on 2026-08-06, so the post could not be re-read from this environment, and it is named as a venue rather than as the source of the figure.
  5. The Chromium change descriptions quoted here are the public commit messages attached to the code reviews cited, not statements issued by Google’s communications or support functions. They are quoted because they describe the user-visible behaviour more precisely than anything published for users did at the time.