Bookmark-related Features

Maybe there is a site whose favicon is always wrong or unhelpful. Overriding this with a good icon would be awesome. Or maybe you would like a work folder with a suitcase icon, while your vacation bookmarks live in a folder with a palm tree and cocktail.
It is an appealing idea.
So why is this not implemented in Bookmark Sidebar?
The Short Answer
The limitation is not primarily the extension itself. It is the browser and the way bookmark extensions are allowed to interact with bookmarks.
Bookmark Sidebar depends on the browser’s built-in bookmark system. It does not maintain a separate bookmark database. Instead, it reads and manages the bookmarks that already exist in Chrome, Edge, and other Chromium-based browsers.
How Bookmark Sidebar Accesses Your Bookmarks
Browsers provide an interface for extensions to work with bookmarks. This is usually called an API.
With the required bookmark permission, the extension can read your bookmarks and perform actions such as:
- opening bookmarks
- editing titles or URLs
- moving entries
- deleting entries
- creating folders
A bookmark entry looks roughly like this:
Each bookmark or folder has an id assigned by the browser. Bookmark Sidebar uses that id internally when interacting with entries.
There are two theoretical ways to add additional data to these entries.
Option 1: Extend the Bookmark Itself
One idea would be to store additional fields directly inside the bookmark:
{
"id": 435,
"title": "My Bookmark",
"url": "https://example.com",
"tags": ["Work", "Microsoft"],
"customIcon": "..."
}
That would be ideal, but browser bookmark APIs do not support arbitrary custom fields.
The browser only stores the fields it understands. Any extra data would simply be ignored.
So this approach does not work.
Option 2: Store Separate Metadata
The second option is to let the extension maintain its own data store:
This metadata would be linked to the bookmark through its browser id.
That sounds workable and technically it is.
But there is a serious problem.
Bookmark IDs Are Not Stable
The bookmark id looks permanent, but it is not guaranteed to stay the same.
Imagine this:
- Bookmark Sidebar stores a custom icon for bookmark id
42 - That bookmark is named Work Login
- Later, the browser changes ids internally
- Work Login becomes id
733
Now id 42 may belong to a completely different bookmark.
That means your custom suitcase icon might suddenly appear on a random recipe website.
Clearly, that would be a disaster.
Why Do IDs Change?
The main reason is browser sync.
If you use multiple devices, bookmarks are synchronized between them.
Example:
- You create a bookmark on your laptop
- It receives a local id there
- It syncs to your desktop PC
- The desktop may already use that id
- So the browser assigns a different one
As a result, the same bookmark can have different ids on different devices.
And sync is not the only cause. Browser updates may also reorganize internal bookmark ids. This has happened before (e.g. in Chrome v142).
How Does the Browser Sync Then?
A fair question is:
If ids change, how does the browser know which bookmark is which?
Most likely, browsers use an internal identifier that remains stable across devices. That hidden identifier powers sync.
The problem is: extensions do not get access to it.
Bookmark Sidebar only sees the exposed bookmark id, not the permanent internal identity.
What Would Be Needed
To support reliable custom icons, tags, notes, and similar features, browsers would need to improve their bookmark API.
Extensions would need access to a stable, never-changing unique identifier for each bookmark.
With that, Bookmark Sidebar could safely attach extra data to the correct bookmark forever.
Current Reality
As things stand today, bookmark-related metadata features cannot be implemented reliably across devices and browser changes.
That is why Bookmark Sidebar avoids adding features that may appear to work at first, but later corrupt data or behave unpredictably.
Sometimes not shipping an unreliable feature is the better decision.