Both protocols let you treat remote storage as if it were a folder on your machine. They are not interchangeable, and choosing the wrong one produces a setup that works in testing and falls apart under real use.
The short version: WebDAV when a person is browsing files, S3 when a program is moving them. The rest of this explains why that line falls where it does.
WebDAV: a filesystem over HTTP
WebDAV extends HTTP with the verbs a filesystem needs - PROPFIND to list a
directory, MKCOL to create one, MOVE and COPY, plus LOCK and UNLOCK for
coordinating concurrent edits.
The design goal was to make a remote server behave like a local disk, and it mostly succeeds. There are real directories, not a naming convention. There is metadata on files. There is a locking model, so two people editing the same document can be made to take turns rather than silently overwrite each other.
One caveat specific to us, because the protocol having a feature is not the same
as a given server enforcing it: the dosya.dev WebDAV gateway grants LOCK and
UNLOCK so Windows Explorer and Office will save, but it does not enforce those
locks between clients. Two people who both hold a lock can both write. If you need
a write to fail when someone else got there first, send If-Match with the file’s
ETag and handle the 412 - that is the mechanism we do enforce. The
WebDAV reference says so alongside the rest of the
limitations.
Its decisive practical advantage is native support. macOS Finder mounts WebDAV
from Go → Connect to Server. Windows maps it to a drive letter. Linux
desktops handle it through GVFS or davfs2. Nobody installs anything, which
matters enormously when the person mounting it is a colleague rather than an
engineer.
Where WebDAV struggles
Every operation is a separate HTTP request, and that is the whole story of its performance profile.
Copying one 2 GB file is fine - a single sustained transfer. Copying 20,000 small files means tens of thousands of round trips, and at 50 ms latency that is inescapably slow no matter how much bandwidth you have. The bottleneck is the number of operations, not the size of the data.
Listing a directory with many thousands of entries is slow for the same reason. And clients have their own limits: the Windows WebDAV client refuses files over 50 MB until you change a registry value, and cannot exceed 4 GB even then. Our Windows walkthrough covers that setting, because the error message does not mention a size limit and it wastes people’s afternoons.
S3: an object store wearing a filesystem costume
The S3 API has no directories at all. What looks like photos/2026/summer.jpg is
a single key in a flat namespace - the slashes are characters, not structure.
Tools display a tree by grouping on prefixes, but the server has none.
This sounds like a limitation and buys a great deal. There is no directory to lock, no tree to walk, and no parent to update when a child changes, so the namespace scales essentially without limit. Listing is paginated and prefix-based, so fetching one “folder” out of ten million objects costs the same as fetching it out of a thousand.
What you get on top is the part that matters for real work:
Multipart upload. Large files are split into parts, uploaded independently and often in parallel, then assembled server-side. A failed part is retried alone, which is what makes very large transfers survivable - the same reasoning as resumable uploads generally.
Range requests. Read bytes 5,000,000 to 6,000,000 of a file without downloading the rest. Video players and analytics tools depend on this.
Presigned URLs. Generate a URL that grants time-limited access to one object, without handing over credentials. This is how you let a browser upload directly to storage instead of proxying gigabytes through your own server.
An ecosystem. rclone, the AWS CLI, and an SDK in every language. If your client is a script, this is decisive - see our rclone guide.
Where S3 struggles
There is no native mounting. Presenting a bucket as a drive requires FUSE - rclone mount, s3fs, mountpoint - which means a kernel extension, macFUSE or WinFsp, and an install step per machine. Fine for a workstation you control, painful for twenty colleagues.
Objects are also immutable. You cannot modify the middle of one; you replace it
whole. Applications that open a file and write to it in place - some editors,
sqlite, most databases - either fail or need a local cache to work against. This
is why rclone mount needs --vfs-cache-mode writes for anything beyond
read-only browsing.
And there is no locking. Two writers produce a last-write-wins outcome with no warning to either.
Choosing, concretely
A designer needs to open and save files in a shared folder. WebDAV. It mounts natively, and the working set is a handful of large files rather than thousands of small ones.
A nightly backup script pushes 200 GB to storage. S3. Multipart upload, parallel transfers, and no interactive session to keep alive. Our server backup guide covers the setup.
A video editor pulls footage into a timeline. S3, through a FUSE mount with a cache. Range requests mean the editor reads the segments it needs rather than whole files.
Someone in accounts needs the invoices folder in Explorer. WebDAV. The alternative is teaching them to install WinFsp, which is not going to happen.
A web application accepts uploads from browsers. S3, using presigned URLs, so the bytes never pass through your application server.
A legacy system expects to drop files somewhere. Probably neither - that is usually SFTP, which such systems already speak.
Using both
These are access protocols over the same storage, not separate products. The same files can be reachable by S3 for your pipeline and by WebDAV for the people who need to look at them.
That is usually the right answer at any scale: scripts take the S3 endpoint, humans mount WebDAV on macOS or Windows, and nobody is forced into the wrong tool because a decision was made once at the beginning.
