WebDAV vs SFTP vs SMB for Remote File Access

The requirement lands on your desk in plain words: "people need to get at the files on that server." Three protocols raise their hands. SMB, the native file-sharing protocol of the office network. SFTP, the file side of SSH. And WebDAV, the file extensions bolted onto HTTP. All three can, in some sense, let a remote user read and write files on a server — which is exactly why the choice deserves ten minutes of clear thinking, because beyond that one sentence they have almost nothing in common.

This comparison, part of our WebDAV series, maps the three protocols across the dimensions that decide real deployments: how each behaves at the firewall, how deeply each is woven into operating systems, what performance to expect near and far, and what each one's security model actually rests on. By the end you will be able to match each protocol to the niche it still owns — and recognize the cases where the honest answer is none of the three.

Three Protocols, Three Family Trees

The fastest way to predict a protocol's behavior is to know where it grew up.

SMB (Server Message Block) grew up on the local network. It is the protocol behind Windows file shares, mapped drives, and the office file server; Linux and macOS speak it fluently too. It was designed for machines a few meters apart on a trusted network: rich file semantics (byte-range locking, permissions, change notifications), deep operating-system integration, and a working assumption that the network is fast, reliable, and private. Our network shares vs file transfer series covers its world in depth.

SFTP (SSH File Transfer Protocol) grew up in the security world. It is a file-operations protocol that runs inside an SSH connection, inheriting SSH's encryption, its single port, and its key-based authentication. It was designed by people whose first requirement was a hostile network: everything encrypted, every endpoint authenticated, nothing optional. It behaves like a very good transfer and remote-operations tool, not like a disk. The full story is in our SFTP series.

WebDAV grew up on the web. It extends HTTP with file-management verbs — listing, uploading, folder creation, locking — so a web server can act as a file store. It inherits the web's genes: stateless requests, URLs, TLS certificates, and effortless passage through any firewall that allows web browsing. We take the protocol apart in how WebDAV extends HTTP.

LAN native, security native, web native. Every row of the comparison that follows is those three origins playing out.

The Firewall's View

For remote access — the scenario where users and server sit on different networks, usually with the internet between them — the first question is brutally practical: will the traffic get through at all, and is it safe to let it?

WebDAV travels as web traffic on port 443. Outbound HTTPS is open on essentially every network on earth — offices, hotels, phones, hospital guest Wi-Fi. WebDAV over HTTPS is indistinguishable at the firewall from ordinary browsing, passes through web proxies, and requires no rule changes on the client side, ever. This is WebDAV's single strongest card. (The occasional failure mode — a middlebox that permits GET and POST but chokes on the extended methods like PROPFIND — is real but uncommon, and fixable at the proxy.)

SFTP travels on port 22. One port, one connection, client to server — clean and simple to publish, and a world away from old FTP's two-connection contortions (a saga our active vs passive FTP series exists to untangle). Inbound, exposing port 22 for file transfer is routine and defensible practice. Outbound is the wrinkle: locked-down corporate networks sometimes block outbound 22 while leaving 443 open, which is worth checking before promising a partner "just connect with SFTP."

SMB travels on port 445, and that port must never cross the internet. This is the item to be absolutist about. Internet-exposed SMB endpoints have been the entry point for some of the most damaging worm and ransomware outbreaks in computing history; consumer ISPs filter the port, and every competent security policy blocks it at the boundary. SMB between sites belongs inside a VPN or private link — full stop. That indirection is workable for site-to-site links you control, and miserable for roaming users and external partners, which is precisely why the other two protocols exist in this comparison.

OS Integration: What Users See

SMB owns this category. Every desktop OS mounts SMB shares natively, completely, and fast: drive letters on Windows, volumes on macOS and Linux. File permissions map through, applications behave normally, and users need zero instruction. On a Windows domain, share access rides the user's existing login with no separate credentials at all.

WebDAV comes second, with caveats. Windows, macOS, and Linux can all mount WebDAV as a drive with built-in tools — no installs — but each client has its temperament: Windows enforces file-size ceilings and strict authentication rules, macOS demands lock support before it allows writes, Linux's davfs2 caches writes locally and uploads later. Our mounting guide walks through every one. The mounts work; they simply need expectations set.

SFTP has no native desktop mount. Mainstream operating systems do not map an SFTP server to a drive letter out of the box. Users interact through client applications — graphical transfer clients, command-line tools, or file managers with SFTP support — and admins script it. Third-party drive-mapping tools for SFTP exist as a category, but "install software on every machine" is exactly the burden remote-access projects hope to avoid. SFTP's constituency is administrators, scripts, and scheduled jobs, and for them the client-app model is no burden at all.

Performance: Near, Far, and Large

All three protocols move bytes at respectable speed on a good network. The differences appear at distance and at scale.

On the LAN, SMB is the benchmark. Decades of optimization — request pipelining, client-side caching with server-granted leases, change notification — make an SMB share feel nearly local. Neither WebDAV nor SFTP matches that interactive feel, and on a LAN there is rarely a reason to use them for day-to-day file access.

Across a WAN, the picture inverts with latency. SMB's rich semantics cost round trips, and although modern dialects batch far better than the protocol's chatty reputation suggests, a mapped drive over 80 milliseconds of latency still disappoints everyone who touches it (the "why does the shared drive crawl over the VPN" phenomenon — examined in the network shares series). WebDAV degrades too — its metadata operations are round trips — but users expect less of it, its reads can fetch byte ranges, and its stateless requests shrug off brief network wobbles that would stall a stateful session. SFTP handles distance best of the three for its own job: transfers are pipelined streams that fill the pipe once running, and interrupted transfers resume from where they stopped.

With large files, the split is sharp. SFTP: transfers resume, no protocol size ceiling, built for exactly this. SMB: capable, given a network path that allows it at all. WebDAV: the weak leg — uploads are all-or-nothing whole-file PUTs with no standard resume, and the common OS clients add their own ceilings (the Windows client tops out around 4 GB). A multi-gigabyte nightly dataset over WebDAV is a bet against your own network; over SFTP it is routine.

With shared editing, SMB again stands alone: real byte-range locking means two users can safely have the same file open in ways neither WebDAV's advisory whole-file locks nor SFTP (no locking model at all) can offer. If simultaneous multi-user editing of the same files is the actual requirement, that requirement quietly mandates SMB — or an application layer above any of the three.

Security Models: Three Kinds of Trust

All three can be deployed securely; they get there along different roads, and the roads determine the operating burden.

WebDAV borrows the web's PKI. Encryption is TLS, proven by a certificate that clients check against the public certificate-authority system — the same machinery as every HTTPS site, familiar to every admin and invisible to every user. Authentication is whatever the web server offers: username and password over TLS at minimum, client certificates where warranted. The catch: TLS is technically optional, so an unencrypted WebDAV endpoint is possible and inexcusable — the case for never allowing one is the spine of securing a WebDAV endpoint.

SFTP brings SSH's model. Encryption is mandatory — the protocol cannot run without it. Servers prove identity with host keys (which clients must learn once and pin), and users can authenticate with keys instead of passwords, which is the foundation of safe unattended automation. There is no certificate authority to pay or renew; the tradeoff is that you manage key trust yourself, and key sprawl is a real chore at scale.

SMB trusts the domain. Inside an Active Directory environment, SMB authentication rides Kerberos: single sign-on, central control, group-based permissions — genuinely excellent. Modern SMB dialects add signing and encryption, and hardening means enforcing them while retiring the legacy dialects (that pass has its own guide in the network shares series). The model's strength is also its boundary: it assumes both ends share an identity infrastructure, which your partners and customers never will.

For exchange across organizational boundaries, this is why SFTP became the default handshake of B2B file transfer: mandatory encryption, no shared domain required, and every platform has a client.

Automation and Scripting

Files that move on schedules move by script, and the three protocols are not equally scriptable. SFTP is the clear first choice: batch modes, key authentication with no interactive prompts, exit codes a script can trust, resume for the transfers that die at gigabyte nine. WebDAV automates acceptably through HTTP tooling — curl can PUT, GET, and even PROPFIND — but scripts inherit the whole-file upload problem and get no standard resume. SMB automation usually means scripting against a mounted path, which is effortless inside a domain and a non-starter across the internet. Scheduled transfer tools reflect the same ranking: a product like Sysax FTP Automation speaks SFTP and FTPS for unattended jobs precisely because those protocols give a scheduled task the retry, resume, and error semantics it needs at 2 a.m.

The Three-Way Table

The whole comparison, condensed for the wall next to your desk:

Which Niche Each Still Owns

SMB owns the building. Same site or VPN, domain accounts, users living in shared folders all day: nothing else comes close, and choosing anything else on a LAN is solving a problem you do not have.

SFTP owns the pipeline. Scheduled jobs, server-to-server feeds, partner exchange across company boundaries, anything scripted or unattended: mandatory encryption, key auth, resume, and universal tooling make it the professional default. It is the protocol of files that move between systems, rather than files that people live in.

WebDAV owns the awkward middle — the cases needing drive-ish, human-facing access across the open internet with nothing installed: the partner who must occasionally browse a document pool, the appliance that can speak HTTP to deposit files, the document platform offering edit-in-place (a niche explored in where WebDAV survives). It is nobody's favorite protocol and everybody's compatibility layer.

And here is the honest fourth option this comparison keeps pointing at: much of what gets deployed as "remote file access" is really just humans occasionally uploading and downloading files. That workload does not need a mounted drive, locking, or POSIX semantics — it needs a browser page over HTTPS with accounts, encryption, and logging. If that describes your requirement, a file transfer server with web access — for example Sysax Multi Server, whose HTTPS support gives users browser-based upload and download alongside its FTP, FTPS, and SFTP services — is simpler to secure and support than any of the three mounting protocols, because the client is a browser everyone already has.

Three Worked Decisions

• A distributed team needs shared project documents, working from anywhere. SMB fails the internet test; SFTP fails the "normal users, no installs" test. WebDAV over HTTPS fits — mount it or browse it — with a sync tool as the alternative if offline work matters. Set the large-file expectations up front.
• A nightly data feed must reach a business partner. Unattended, scripted, across organizations, possibly large: SFTP, keys not passwords, scheduled with retries. This is its home turf, and it is what the partner's IT team will expect you to propose.
• One office, one domain, everyone on the LAN. SMB shares, as always. Reserve the remote protocols for the people and systems that leave the building — and resist the temptation to expose the share itself to make that happen.

The Version to Tell a Colleague

Three protocols, three homelands. SMB is the LAN's native file system — unbeatable in the building, forbidden on the internet. SFTP is the security world's transfer tool — encrypted always, scripted beautifully, mounted natively nowhere. WebDAV is the web's filing cabinet — crosses any firewall as HTTPS, mounts on every desktop with quirks, and struggles with large files. Pick by where the users are, what crosses the internet, and whether a human or a schedule is driving. And when the real requirement is just browser-based upload and download, skip the mounting protocols entirely and serve it over plain HTTPS.

To go deeper on the WebDAV corner of this map: how the protocol actually works, mounting it on each OS, and securing an endpoint before it faces the internet.

Frequently Asked Questions