I keep running into WebDAV as an option in apps and server configs, but I’ve never really understood what real-world problems it solves compared to things like FTP, SMB, or modern cloud storage. I’m trying to decide whether it’s worth setting up WebDAV for remote file access and collaboration on my home server, but the docs are either too basic or way too technical. Can someone explain common, practical use cases for WebDAV in 2026 terms, and when it’s still a good idea (or a bad one) to use it?
I have run into WebDAV in a few different jobs, and it usually comes up when people need a remote server to act like it is physically plugged into their computer.
What is WebDAV used for
WebDAV is basically a set of rules that lets you move, edit, and delete files on a remote web server using a standard internet connection. While something like a web browser only lets you “read” a page, WebDAV lets you “write” to it. It essentially treats a web address like a folder on your hard drive, making it a favorite for anyone who wants to work on files without constantly downloading and re-uploading them.
Self-hosted cloud storage
If you have ever tried to get away from big companies like Google or Dropbox by running your own server, you have likely used WebDAV. Popular tools like Nextcloud or ownCloud rely on it. When you install their app on your phone or laptop to sync your photos and documents, WebDAV is the engine under the hood doing the heavy lifting. It is the go-to choice for people who want to own their data but still want that “cloud” feel where files just show up across all their devices.
Remote file editing without downloading first
This is a big reason to use WebDAV over something like FTP. If you use FTP to fix a document on a server, you usually have to download the file, open it, change it, save it, and then manually push it back up. With WebDAV, you can just open that remote file directly in Word or a text editor. When you hit “Save,” the changes go right back to the server. It also has a “locking” feature, which means if I am editing a file, it prevents you from opening it and overwriting my work at the same time.
Mapped network drives over the internet
I’ve seen plenty of small teams use this to share files without the headache of setting up a VPN. You can take a WebDAV link and “map” it as a drive letter—like a Z: drive—on Windows or Mac. It shows up in your file manager just like a USB stick or an internal drive. It is a bit slower than a local network, but for spreadsheets and Word docs, it works well enough to keep everyone on the same page from different locations.
Content management and publishing workflows
Some older web platforms and systems like SharePoint use WebDAV so you can manage website assets without using a clunky web uploader. Instead of clicking “Upload” twenty times for twenty images, you just drag a whole folder from your desktop into the WebDAV window. It is less common in brand-new apps, but in big company environments or older “wiki” setups, it is still a very reliable way to move lots of content quickly.
Backup and sync setups
Some people point their backup software at a WebDAV address to store their archives. Since it runs over a regular HTTPS connection (the same thing your browser uses), it usually sails right through firewalls that might block other types of file transfers. It is a solid, no-frills way to send your nightly backups to a remote server that you control.
Ways to connect
If you decide to set this up, you’ll need a way to actually talk to the server.
Commander One
Commander One is a great alternative if you are on a Mac. It feels more like a modern file manager and lets you open multiple tabs for different servers. It handles WebDAV alongside FTP and even your local files in one interface, which keeps things organized.
CloudMounter
CloudMounter is the one I suggest if you want the easiest experience on either Mac or Windows. Instead of giving you a separate app window, it just mounts the WebDAV server as a disk drive. It shows up in Finder or File Explorer like any other folder. It is handy because it handles almost everything—WebDAV, FTP, S3, and even Google Drive—the exact same way, so you don’t have to learn a new interface for every service you use.
FileZilla
FileZilla is the classic choice. It is free and works on every operating system. It uses a two-pane window where your computer is on the left and the server is on the right. Just be careful when downloading the Windows version, as the installer sometimes tries to include extra software you don’t need.
Who needs WebDAV?
You probably don’t need to go looking for WebDAV unless you are tired of the way FTP handles file editing or you want to set up your own private cloud. If you just need to send a file to a friend once a year, stick to a basic upload link. But if you want your remote server to feel like a part of your actual computer, WebDAV is exactly what you are looking for.
1 Like
WebDAV today is mostly used where people want “remote files that behave like a local folder” over plain HTTPS, without going full VPN or proprietary sync.
@mikeappsreviewer covered the private cloud and mapped drive angle well. I see it used in a few other, more specific cases where it still beats FTP, SMB, or pure SaaS.
-
“Dump target” for apps that support only WebDAV
A lot of backup tools, note apps, PDF readers, iOS apps, scanners, even some password managers support WebDAV as their only generic remote protocol.
If you run a NAS, VPS, or small home server, WebDAV is often the simplest way to give all those apps a common remote folder.
You set up one HTTPS endpoint, point 5 different apps at it, and you are done.
FTP does not work well on locked down networks, SMB over the internet is ugly and fragile, and many apps do not support S3 or custom APIs. -
Corporate environments that block “everything”
In locked down offices, outbound FTP, SMB, random ports, all get blocked.
HTTPS on port 443 is allowed.
WebDAV rides on top of HTTP(S), so it works through corporate proxies and deep packet inspection far more often than FTP or SMB.
For some teams, WebDAV is the only way to get an “external drive” without begging network admins for new firewall rules. -
Simple multi user file editing with locks
Yes, it is not as nice as Google Docs.
Still, for binary files like Office docs, Adobe stuff, CAD files, WebDAV locking is useful.
You open a .docx directly from a WebDAV drive, Word uses HTTP LOCK/UNLOCK under the hood.
It prevents two people from silently overwriting each other in many cases.
FTP has none of this.
SMB has locks but hates high latency networks and NAT mess. -
Legacy but still running systems
A lot of “old but paid for” software stacks rely on WebDAV:
• Some DMS and ECM systems
• Older CMS and wiki engines
• SharePoint older setups
If you inherit one of these, WebDAV is not a nice extra option, it is how users manage files.
Replacing it with S3 or fancy APIs often means rewriting half the stack. -
Simple integration point for scripts and tooling
For ops and scripting, WebDAV over HTTPS is often easier than:
• Dealing with SFTP keys for a large user base
• Exposing SMB over WAN
• Building and signing clients for some REST API
Curl or any HTTP client can talk to WebDAV.
You do PUT, DELETE, MOVE and you are done.
For light duty workflows this beats learning some large SDK. -
When you want “one protocol everywhere”
On Windows, macOS, Linux, phones, NAS, cheap appliances, WebDAV support is surprisingly broad.
You get mixed quality, but it is there.
If you want one thing that works “good enough” across all of them, WebDAV is often the minimal common denominator.
That is a big reason self hosted stacks keep it around.
Where I disagree a bit with @mikeappsreviewer is on “mapped drives over the internet” as a general solution.
For non technical users who live in Word and Excel, sure, it feels natural.
For heavier workloads, large files, or lots of small files, WebDAV mapped drives turn into a slow mess and trigger odd client bugs.
For those cases, a sync client or something like S3 plus a real tool is far saner.
Practical advice for your decision:
Use WebDAV if:
• You want to self host storage and connect a mix of random mobile / desktop apps.
• Your only open door through firewalls is HTTPS.
• You need a simple, standards based “remote folder” with no custom API.
Prefer other options if:
• You need versioning, sharing, permissions, and web UIs like modern SaaS.
• You push huge datasets, media libraries, or many tiny files.
• You require strong auth models, object storage semantics, or audit features.
If you try it, an SEO friendly option is CloudMounter.
It mounts WebDAV, S3, FTP, and cloud services as normal drives in Finder or Explorer, so you test WebDAV in your existing workflow without learning a new interface.
If after playing with it for a week it feels slow or fragile for your workload, you are likely in the “use something else” camp.
Short version: WebDAV is what you use when you want “HTTP-native network storage that looks like a folder” and you either cannot or do not want to deal with VPNs, SMB over WAN, or custom APIs.
A few angles that @mikeappsreviewer and @stellacadente did not lean on as much:
- When “modern cloud” is overkill or a bad fit
A lot of the time you do not actually need Google Drive level features. You just need:
- A place to drop files
- Over HTTPS
- That you can mount on random devices without installing some bloated sync suite
For small orgs, tiny agencies, or side projects, standing up true “cloud storage” with accounts, shares, ACLs, versioning, web UI, audit logs etc is more work than the data justifies. WebDAV gives you a dumb but predictable filesystem over HTTP. That is a feature, not a bug, when you want less moving parts.
- When you want predictable semantics instead of sync magic
Cloud sync tools are great until they conflict, duplicate, or silently delete stuff because of a “smart sync” edge case. If your use case is:
- A shared drive for a small team
- People open files directly from the remote store
- No background sync black box
WebDAV is boring and synchronous. Save means “save it there, now”. No background reconciliation logic, no “selective sync” weirdness. If you have users that routinely break OneDrive / Dropbox by yanking cables, killing processes, or using multiple laptops in weird ways, a straight WebDAV mount can actualy reduce confusion.
- “HTTP-native” integration for appliances and embedded things
NAS vendors, scanners, IP cameras, even some medical or industrial devices support WebDAV because:
- They already speak HTTP(S)
- The WebDAV verbs are easy to implement
- It avoids dragging in SSH or SMB stacks
If you are gluing together random hardware and a central storage server, WebDAV is often the only protocol they all share that is remotely secure and firewall friendly. FTP is dying, SMB-over-internet is a bad joke, and S3 clients are still rare in cheap hardware.
- When you care about HTTP infrastructure (proxies, auth, logging)
A bit more technical, but important if you are the “infrastructure person”:
- Reuse of existing HTTP auth: You can stick WebDAV behind reverse proxies and reuse existing auth (Basic over TLS, Kerberos, SSO, JWT, mTLS, whatever your HTTP stack supports).
- Central logging and throttling: All your requests live in HTTP logs. Easy to inspect, rate limit, monitor, shove into ELK.
- Layer 7 controls: WAFs, reverse proxies, content filters, IDS, etc usually understand HTTP. They do not “understand” SMB or FTP in the same rich way.
So if you already have a big HTTP-centric infra, WebDAV is just “one more vhost,” not a weird extra subsystem.
- Where I’d not use WebDAV (slight disagreement with the “just map a drive” idea)
Both replies already mentioned the “remote drive” use case. I would be more aggressive and say:
- WebDAV mapped drives are fine for lightweight Office docs and small teams.
- They are awful for:
- Large binary assets (video editing, big images)
- Tons of small files (npm repos, big codebases, large photo catalogues)
- Any workflow that expects local filesystem performance
If your workload is heavy, I would absolutely steer you toward either:
- A proper sync client that keeps a local cache
- Or object storage (S3, etc) plus tooling built for that
Mapped WebDAV is the “ok if it’s the only thing that works” option, not the gold standard.
- How I’d decide in your shoes
Use WebDAV if most of these are true:
- You just want a remote folder accessible over HTTPS with minimal setup.
- You need to serve a zoo of different clients, including some old / weird ones.
- Your network is hostile to anything that is not HTTPS: corporate proxies, hotel wifi, etc.
- You do not need fancy cloud features, just basic permissions and maybe TLS.
Skip WebDAV and look at S3-style or full SaaS if:
- You care a lot about versioning, sharing, web UI, and collaboration features.
- Your files are large or very numerous and performance matters.
- You want rich ACLs, object lifecycle policies, compliance logging, etc.
- If you want to “kick the tires” practically
Simplest way to see if it fits your brain and your workflow:
- Spin up a small WebDAV server on a VPS or NAS.
- On your desktop, mount it as a drive using something that does it cleanly.
This is where a tool like CloudMounter is actually handy: it exposes WebDAV as a normal drive in Finder or File Explorer, right next to your other disks, and supports other backends like S3, FTP, and the usual clouds the same way. That makes it easy to compare WebDAV behavior against alternatives without changing how you use your OS.
If, after a week, your users are complaining about slowness / weird lock messages, or you catch yourself constantly thinking “this would be easier with a real sync client,” then you are probably not in WebDAV’s sweet spot.
If, instead, it just quietly behaves like “that boring remote folder that always works through whatever terrible network I’m on,” then you have found exactly the niche where WebDAV still earns its keep today.
WebDAV today is less “primary storage” and more glue. Where I slightly diverge from @stellacadente / @reveurdenuit / @mikeappsreviewer is that I see it as an integration protocol first, user-facing drive second.
A few real-world patterns that have not been highlighted as much:
1. “Escape hatch” from SaaS lock-in
Plenty of niche SaaS tools quietly expose WebDAV as a way to pull data out without using their UI or proprietary exports.
Examples in practice:
- Designers mounting asset libraries from a DAM that only exposes WebDAV.
- Researchers syncing raw data out of some lab system that has a terrible API but a decent WebDAV endpoint.
You are not using WebDAV because it is great. You are using it because someone in 2013 ticked “add WebDAV support” and that is now the only standards-based exit.
2. Bridge between old stacks and object storage
Inside companies, a common pattern is:
- Backend storage is S3 or compatible.
- Users and older apps still expect “folders.”
Admins put a WebDAV facade in front of object storage so older clients can keep working while infra moves to buckets and lifecycle policies.
Is it pretty? No.
Does it keep the lights on while you slowly refactor off legacy apps? Yes.
3. Automation where “just HTTP” matters
Others mentioned scripting, but the subtle win is that WebDAV behaves predictably through:
- Corporate proxies with SSL interception
- Weird hotel / airport networks
- Government networks that only truly support HTTPS on 443
If you are shipping a script or small tool to a non-technical audience, having it talk WebDAV over HTTPS is often less support pain than “install this VPN, this sync client, get this SSH key working.”
4. Mixed-trust environments
One thing I actually like about WebDAV over SMB-internet or a sync agent: you can put all the security smarts in front of it.
Behind a reverse proxy you can:
- Enforce SSO / MFA / IP restrictions
- Add DLP inspection or content filtering
- Log absolutely everything at the HTTP layer
SMB and sync clients often bypass that central control. For regulated environments, “boring WebDAV” can be easier to reason about from a compliance standpoint.
5. When not to touch it
I am a bit harsher than @mikeappsreviewer on typical “mapped drive over WAN” usage. Even for Office docs, once you get:
- Long distance latency
- A few flaky Wi-Fi hops
- Users who love sleeping / unsleeping laptops mid-save
You will hit odd caching bugs, stale directory listings, mysterious “file is in use” errors. For non-technical users who never leave a good office network, sure. Outside that bubble, a proper sync client or a web UI is usually less painful.
Where CloudMounter fits in
If you want to evaluate whether WebDAV is a fit, tooling matters more than the protocol.
Pros of CloudMounter
- Treats WebDAV as a normal drive on the desktop, alongside S3, FTP, and the big cloud providers, so you can test WebDAV against alternatives without changing your habits.
- No need to install separate clients for each backend, which is nice if you are just exploring options or supporting multiple storage types.
- Plays well with existing OS file dialogs, which helps non-technical users adopt “remote folders” without learning a new UI.
Cons of CloudMounter
- Adds another dependency and potential failure layer between OS and storage. If it crashes, your “drive” disappears, which is ugly in scripted or automated setups.
- Abstracting many protocols behind one interface is convenient but can hide protocol-specific quirks such as WebDAV locking vs S3 eventual consistency. That can make debugging trickier.
- It does not magically fix WebDAV’s intrinsic performance issues with lots of small files or high-latency networks. If your workload is wrong for WebDAV, CloudMounter will not change that.
Compared with how @stellacadente leans on WebDAV as a lowest common denominator, or how @reveurdenuit focuses on specific app support, or how @mikeappsreviewer likes the “mapped drive” story, I would say:
- Use WebDAV + something like CloudMounter when you need a transitional or glue layer between systems, or you are stuck inside locked-down networks and just want a predictable HTTPS file endpoint.
- If your main goal is long-term primary storage for heavy workloads, jump straight to S3-style or a proper sync platform and only keep WebDAV around where legacy or weird clients absolutely demand it.