Filebrowser is a lightweight Go web UI over an existing directory - the original is in maintenance-only mode, and most modern features live in the community fork Filebrowser Quantum. Cotton is a full storage engine with encryption, previews, and recovery. This is not a scoreboard with fake certainty; it is a product-fit comparison for self-hosted file cloud decisions.
Filebrowser points at a directory and shows the plain files already there - nothing is chunked, deduplicated, or content-addressed. Cotton is the storage layer itself: a content-addressed chunked engine. Filebrowser shows your filesystem; Cotton is one.
Filebrowser stores files as plaintext and closed its at-rest-encryption request as not planned; there is no client-side or end-to-end option in either the original or the Quantum fork. Cotton does streaming AES-GCM by default plus client-side E2E folders.
The original Filebrowser is username and password with no 2FA or passkeys; the Quantum fork adds OIDC, LDAP, and 2FA - credit where due. Filebrowser previews images, text, video, and PDF; Cotton adds audio waveforms, STL/OBJ/3MF 3D, HEIC, mobile PDF text, and video seek on encrypted storage.
Pick Filebrowser when you already have files in a directory and just want a clean window onto them with near-zero setup and no database - your backups and rsync read those plain files directly. Pick Cotton when you want an engine that encrypts, deduplicates, previews, and recovers.
Cotton does not need to beat every long-established ecosystem on every surface. The useful comparison is narrower: storage behavior, privacy posture, recovery model, deployment shape, and product focus.
Cotton stores file content as chunks and manifests, so deduplication, verification, versions, snapshots, and cleanup share one mental model.
Compression and AES-GCM encryption sit in the normal storage path; the site does not sell isolated crypto speed as user-visible ingest speed.
Snapshots, versions, trash, and reclaim are positioned as ordinary file-cloud workflows, not emergency-only backend chores.
Cotton deliberately stays narrower than broad collaboration suites: files, previews, sharing, WebDAV, recovery, and operator visibility.
Cotton is the cleaner story when files, previews, shares, snapshots, versions, WebDAV, passkeys, admin diagnostics, and a compact Docker/Postgres deployment are the main problem.
People who just want a clean browser over files that stay as plain files on disk.
You want a focused self-hosted file cloud with content-addressed storage, streaming crypto, snapshots, previews, WebDAV, sharing, passkeys, and a compact Docker deployment.
You need a dead-simple web UI over an existing folder, with a tiny footprint and no external database more than the Cotton storage-engine and recovery-model strengths.
Cotton is not trying to be a bigger suite than Filebrowser. It is trying to be the sharper file cloud when the file engine itself is the product decision.
If you want encryption, dedup, rich previews, and recovery, Cotton is the engine, not just a window.
Last reviewed June 2026. Every line below links to its receipt - the actual issue, doc, or commit it came from. Competitors move fast; if a link goes stale, open an issue and we fix it.
Receipts
Not always. Cotton is a focused file cloud, not a clone of every app and integration in the older ecosystems. It fits best when file storage, previews, sharing, snapshots, WebDAV, security, and deployment simplicity are the main problem.
Because people searching for a self-hosted file cloud often start with the familiar names. The comparison makes the tradeoff explicit instead of pretending every product has the same goal.
If you want a dead-simple web UI over an existing folder with a tiny footprint, no external database, and files that stay as plain files your other tools can read, Filebrowser is purpose-built for that. Cotton is the fit when you want an engine that encrypts, deduplicates, previews, and recovers.