How Floccus Handles Privacy and Where Your Bookmark Data Is Stored

Floccus does not store your bookmarks on its own servers. Your data lives in the storage service you choose—Nextcloud, Linkwarden, KaraKeep, Git, WebDAV, Google Drive, or Dropbox—and Floccus acts only as the sync client between your browsers and that backend. The project states it has no ads and no data collection, and it is free and open source software. Some backends support end-to-end encryption (E2EE). These conditions apply to the browser extensions and the mobile app as described on floccus.org; the site does not publish a separate privacy policy page in the provided material, so treat the "no data collection" claim as the project's own statement rather than an audited guarantee.

Where your bookmarks actually live

The storage location depends entirely on the service you connect. Floccus syncs bookmarks (and tabs) through one of these backends:

The practical consequence: if you self-host Nextcloud, Linkwarden, or KaraKeep, or point Floccus at your own WebDAV share or Git repository, the bookmark file never touches a third-party cloud. If you choose Google Drive or Dropbox, your bookmarks sit in that provider's storage under your account, and the privacy properties of that provider apply.

What "no data collection" means in practice

Floccus describes itself as syncing "and getting out of your way; no ads, no data collection, no nonsense." In plain terms, the sync client is not a analytics product: there is no advertising layer and no described telemetry pipeline sending your bookmark contents to the Floccus project. Because the software is open source, you can inspect the code yourself rather than relying on the statement—this is the main verifiable privacy claim the project makes.

One caveat worth knowing: the mobile app "currently only syncs to a folder in the mobile app, not to mobile browsers," and Floccus support across mobile browsers is described as sparse. So on mobile, your synced data is held inside the app's own folder until you move it, which is a storage-location detail rather than a privacy guarantee.

End-to-end encryption: which setups get it

E2EE is the feature that matters most if you use a third-party cloud. The feature matrix marks E2EE as available for Nextcloud, WebDAV (in parentheses), Google Drive (in parentheses), and Dropbox (in parentheses), while Linkwarden, KaraKeep, and Git are marked as not offering it. The parenthetical marks suggest a qualified or partial implementation rather than a full guarantee, so if E2EE is your deciding factor, confirm the current behavior for your specific backend before committing.

A concrete example of when this matters: suppose you keep bookmarks in a shared Dropbox account. Without E2EE, anyone with access to that Dropbox account can read the synced xbel/html file directly. With E2EE enabled, the file stored in Dropbox is encrypted, and the key stays with your Floccus clients—so account access alone does not expose bookmark contents. The same logic applies to a WebDAV share on a rented server.

Self-hosting as the strongest privacy option

If your priority is data autonomy, the self-hosted backends are the clearest path: Nextcloud Bookmarks, Linkwarden, KaraKeep, a WebDAV share you control, or a Git repository over HTTPS. In these setups you decide where the data is stored, which is exactly the control the project emphasizes—one user quoted on the site puts it as "respects privacy: you decide where your data are stored."

The trade-off is operational: you run and maintain the server, and you accept that E2EE availability varies by backend (Nextcloud yes, Linkwarden and KaraKeep no, WebDAV qualified). For a personal Nextcloud instance on hardware you control, E2EE plus self-hosting gives you both encryption and custody.

How to check your own setup

1. Identify which backend you configured in Floccus (the service name appears in your sync profile).
2. Look up that backend in the feature matrix above to see whether E2EE is supported, partial, or absent.
3. If E2EE is available, enable it in the sync profile before the first sync so existing bookmarks are encrypted from the start.
4. Verify by inspecting the stored file in your backend—an encrypted payload should not be readable as plain bookmark titles and URLs.
5. If you need full custody, migrate to a self-hosted backend (Nextcloud, WebDAV, or Git) rather than a consumer cloud.

Common sticking points: E2EE marked with parentheses may behave differently across versions, so check the release notes for your version; the mobile app's folder-based sync means mobile bookmarks are not automatically shared with mobile browsers; and Safari is not supported due to technical limitations, so Safari users cannot rely on Floccus for that browser at all.