Bookmark LONG IDs is a deliberate update in Brave version 1.96.59

The change from short numeric IDs to long UUIDs I can understand… What I don’t understand is why the long UUID change everytime Brave is closed?

If this “feature” continues then the utility of bookmarks simply disappears.

Please do try to solve the code update and make it better again!

@msb

Brave Support will very likely want to know what exactly you are using/looking at to obtain the bookmark IDs?

cc: @Mattches

ChatGPT:

Chromium recently changed the bookmark WebUI architecture. On August 6, 2026, Chromium landed a change explicitly titled:

“Add UUID mapper and update BookmarksView for Bookmarks WebUI Mojo migration.”

The change introduced BookmarkUuidMapper and changed the bookmark WebUI/API from using the bookmark’s native UUID directly to using a separate API UUID.

The new mapper does this when it encounters a bookmark:

base::Uuid::GenerateRandomV4()

It therefore creates a random UUID for the API representation of the bookmark. The mapping is held by the BookmarkUuidMapper itself. Chromium’s own comments say that the API UUID is an indirection layer between the external API and the underlying bookmark model identity.

The old behavior was essentially:

bookmark node → its persistent UUID

The new behavior is:

bookmark node → BookmarkUuidMapper → randomly generated API UUID

The mapper retains that generated UUID while the mapper exists, but there is no indication that those API UUIDs are persisted to the bookmark database. In fact, the code has explicit Clear() and ClearAllExcept() operations on the in-memory mappings.