Floccus: private bookmark sync between browsers without a vendor account

The problem Floccus solves: bookmark sync when you do not want a bookmark vendor

Browser sync services keep bookmarks inside the browser vendor's account. If you use Firefox on a laptop, Chrome on a work machine and a phone, you either accept three separate bookmark sets or you accept one vendor's account as the hub. Floccus takes a third path: it reads and writes the browser's own native bookmark tree and pushes that tree to a storage backend you choose. The README lists Nextcloud Bookmarks, Linkwarden, KaraKeep, Google Drive, Dropbox, any Git server such as GitHub, GitLab or Gitea, and any WebDAV-compatible service. That list matters because it splits Floccus from tools that own the bookmark data. With Floccus the canonical copy can live in your Nextcloud instance or a Git repository, and the browser is one client among several.

The audience is narrow and identifiable. You are comfortable running or paying for one of those backends. You use more than one browser profile or device. You want the bookmarks to stay in the browser's own bookmark UI, not in a separate reading app. The README also states that most mobile browsers do not support Floccus, which is why the project ships its own Android and iOS app for phone access. If your phone workflow depends on your mobile browser's built-in bookmark list, Floccus does not cover that.

How Floccus syncs: profiles, sync strategy and the storage backend

The unit of configuration is the sync profile. The README says you can create as many as you need and that each profile controls the sync strategy (unidirectional or bidirectional), the sync interval and the synced folder. A profile binds three things: a browser-side folder, a backend account or endpoint, and a direction. Multiple profiles let you, for example, mirror one folder to a Git repository read-only while running a two-way Nextcloud profile on a different folder.

Bidirectional mode is the part that deserves attention before you enable it. Two clients that both add, move and delete entries against the same backend will produce conflicts, and the project's own CONSIDERATIONS.md file exists precisely because the author considered whether this design is a good idea. The README points to that file rather than summarising the argument, so read it before you decide how aggressive your interval should be. A conservative setup is one bidirectional profile per backend with a long interval, plus unidirectional profiles for any device you only want to read from.

The backend is not abstracted away. Nextcloud Bookmarks, WebDAV, Git and the file-hosting APIs are different storage models with different failure modes, and Floccus has to map a bookmark tree onto each. The README's troubleshooting section gives one concrete example of that friction: MySQL and MariaDB do not support emojis out of the box, so syncing to Nextcloud can return an HTTP 500, and the fix is a database charset change documented by Nextcloud. That is a storage-side problem surfacing as a sync error, and it is the kind of issue you will meet again with other backends.

Installing Floccus and running a first sync profile

Floccus is distributed as a browser extension, not as an npm package you run yourself. The README's download badge points to floccus.org/download, and the guides for first-time setup live at floccus.org/guides. The repository is the source for the extension and the mobile app; the build scripts in package.json are aimed at producing those artifacts, not at end users. So the install path is: add the extension from your browser's add-on store, then configure a profile inside it.

The repository does document the build path for anyone packaging it. The build script is a gulp task with a raised Node heap, and there are Windows variants of the same commands.

npm run build
npm run build-win

The README does not spell out profile fields in code, so treat the extension UI as the source of truth for exact labels. What the README does commit to is the shape of a profile: a backend account, a sync strategy, an interval and a folder. A first run should therefore be deliberately small. Create one profile, point it at a test folder rather than your live bookmarks, choose the unidirectional direction, and set a long interval. Confirm the backend received the entries before you widen the scope.

The README also states that you can export your configuration. Do that immediately after the first profile works, because it gives you a restorable description of what you configured without re-entering backend credentials by hand.

Where Floccus is the wrong tool

Safari is not supported. The README links to issue 23 and says Safari is supported "not yet". If Safari is one of the browsers you need in the loop, Floccus cannot be the whole answer today, and no amount of backend configuration changes that.

Mobile browsers are the second gap, and it is structural rather than temporary. The README states plainly that most mobile browsers do not support Floccus, which is why the project builds its own Android and iOS app. That app is a separate client with its own release channel. The README publishes the SHA-256 fingerprint of the certificate used to sign the floccus APKs, which is useful if you sideload, but it also tells you that installing on Android is a distinct step from installing the extension.

The third case is the one people underestimate. Floccus does not provide storage. If you do not already run Nextcloud, a WebDAV endpoint or a Git remote, you are adopting two systems, and the failure you will actually debug is the backend's. The emoji and charset problem in the README is the pattern: a database-level constraint in your storage shows up as a sync failure in the browser. If you want someone else to be responsible for the canonical store and its schema, a bookmark service with its own backend is a better fit.

Floccus compared with Linkwarden, xBrowserSync and Raindrop-style services

Linkwarden appears in the Floccus README as a supported backend, which makes the comparison unusual: they are not simply competitors. Linkwarden is a self-hosted bookmark manager with its own web application, and Floccus can sync your browser bookmarks into it. The difference in approach is where the primary interface lives. With Linkwarden you read and organise bookmarks in Linkwarden's UI. With Floccus pointed at Nextcloud or WebDAV, you keep working in the browser's bookmark manager and the backend is closer to a relay plus an archive.

xBrowserSync is the closer functional equivalent, because it is also a browser extension whose job is syncing bookmarks across browsers. The distinction the Floccus README makes is the backend list: Nextcloud Bookmarks, WebDAV, Git, Google Drive, Dropbox, Linkwarden and KaraKeep. That breadth is the point of Floccus. If you already have a Git repository you trust, or a Nextcloud instance, Floccus can use it directly rather than requiring a service built for bookmark sync.

Raindrop-style services take the opposite position. They are hosted, they own the store, and they give you apps and a web UI. You get less setup and less control. Floccus asks you to accept the setup cost in exchange for the store being yours. Neither is wrong; they fail differently. A hosted service fails when the vendor changes terms or pricing. Floccus fails when your WebDAV endpoint, Nextcloud database or Git remote does.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-21. Recent releases are v5.10.1 on 2026-07-03, v5.10.2 on 2026-07-18 and v5.10.3 on 2026-08-30, and package.json carries version 5.10.3. The CHANGELOG.md file at the repository root is where release notes live; the README does not summarise them.

Licensing is MPL-2.0, stated in package.json and shipped as LICENSE.txt. The Mozilla Public License is file-level copyleft: modifications to MPL-covered files must be made available under the same licence, while larger works that combine MPL files with other code can be licensed differently. If you fork Floccus or embed it in a product, read LICENSE.txt and the MPL itself rather than relying on that summary; this is not legal advice.

The upgrade cost is mostly on the backend side. Because Floccus writes into Nextcloud Bookmarks, WebDAV, Git or a file host, an extension update that changes how it maps folders can interact with data your backend already holds. The README does not document rollback, and it does not describe a migration procedure for profiles across major versions. Exporting your configuration, as the README says you can, is the practical mitigation available to you today.

Editorial conclusion

Adopt Floccus if you already run Nextcloud Bookmarks, a WebDAV endpoint or a Git remote and want your real browser bookmarks folder synced across Firefox, Chrome and the Android or iOS app without a bookmark vendor account. Skip it if you need Safari, if you are not willing to operate and back up the storage side, or if you expect a hosted service to do that for you. Before committing, open the extension's settings, export your configuration as the README describes, and create one unidirectional profile against a test folder to confirm the storage endpoint accepts writes before you point a bidirectional profile at your live bookmarks.

Frequently asked questions

Official sources

1. floccusaddon/floccus on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases