When HTTPS Beats SFTP: Choosing Web-Based Transfer

Sooner or later every administrator referees this argument. One camp says "just give them an SFTP account like we always do." The other says "nobody wants to install a client — send them a link." Both camps are right about something, both protocols encrypt traffic properly, and the argument goes in circles because it is being had at the wrong level: this is not a security decision or a fashion decision. It is a workflow fit decision, and the two protocols fit different workflows for concrete, explainable reasons.

This guide lays out those reasons without cheerleading. You will get the cases where HTTPS genuinely wins (client-less delivery, hostile firewalls, non-technical recipients), the cases where SFTP genuinely wins (scripted batch work, standardized semantics, partner expectations), the tradeoffs each choice quietly accepts, and a decision matrix you can apply in ten minutes. By the end, you should be able to end the argument in one meeting — sometimes with the answer "both."

This article is part of our HTTP/HTTPS File Transfer series; the SFTP side of the story has a full series of its own.

Two Protocols, Two Worldviews

Start with what each thing actually is, because the names invite confusion.

HTTPS is HTTP — the web's request-response protocol — wrapped in TLS encryption. File transfer over HTTPS means the file rides inside web requests: a download is a GET, an upload is a POST or PUT (mechanics dissected earlier in this series). Its defining property: the client is everywhere. Every laptop, phone, and kiosk on earth ships with a capable HTTPS client called a browser, and every network that permits any internet use at all permits outbound HTTPS on port 443.

SFTP is a file-operations protocol that runs inside an SSH session (the encrypted remote-access channel admins already use). Despite the name, it is not FTP-with-something-added — FTP-over-TLS exists and is called FTPS, a different protocol family; the untangling lives in our SFTP vs FTPS vs FTP series. SFTP's defining property: the operations are standardized. Upload, download, list directory, rename, delete, resume — every SFTP server speaks the same verbs the same way, which is why a script written against one SFTP server works against any other.

Hold those two properties in mind — client everywhere versus semantics everywhere — because nearly every practical difference flows from them.

Security: Mostly a Tie, Honestly

Modern HTTPS and modern SFTP both encrypt traffic with well-studied cryptography, both authenticate the server to the client, and both protect credentials in transit. Neither is "the secure one." The genuine security differences are structural, not strength-related:

• Trust models differ. HTTPS servers prove their identity with certificates issued by certificate authorities the client already trusts — which is why browsers connect to a properly configured HTTPS server with no warnings and no setup. SFTP servers prove identity with host keys that each client must accept and pin on first contact — stronger against some attacks once established, but that first-connection prompt is exactly the kind of dialog untrained users click through blindly.
• Authentication conventions differ. HTTPS inherits the web's whole login toolbox (forms, sessions, single sign-on). SFTP inherits SSH's: passwords or, better, key pairs — ideal for machine identities, awkward to explain to a marketing contractor.
• Exposure profiles differ. An HTTPS endpoint is a web application and inherits web-application attack surface; an SFTP endpoint inherits SSH's, including the internet's constant background of SSH login attempts. Both are manageable; both need patching, logging, and rate limiting.

Conclusion: pick on workflow, then secure whichever you picked properly. The rest of this guide is about workflow.

Where HTTPS Wins

The client-less advantage. The strongest card in the deck. Delivering or receiving a file over HTTPS requires the other party to have — nothing. No installation, no configuration, no admin rights on their machine, no support call teaching a vendor's accounting department what a host key is. For non-technical recipients, the difference between "click this link" and "install and configure this SFTP client" is the difference between a transfer that happens today and a ticket that ages for a week. If your counterpart cannot or will not run software, HTTPS is not just better; it is the only realistic option.

Firewall friendliness. Outbound 443 is open on effectively every network — corporate, hotel, hospital, guest Wi-Fi — because blocking it means blocking the web. One TCP connection carries the whole HTTPS conversation, so there is no data-channel negotiation to break (the multi-connection fragility that plagues FTP, chronicled in why firewalls block active FTP, simply does not exist here). SFTP's port 22 usually works too — but "usually" is the operative word: plenty of locked-down environments block or intercept non-web egress, and when your counterpart is inside one, HTTPS traverses where SFTP cannot.

Web-native workflows. Because the transfer is web traffic, it composes with everything else that is web: a download link pasted into email, an upload page embedded in a portal, a presigned URL granting temporary access with no account at all, a REST API moving files as part of an application. SFTP has no equivalent of "click here."

Distribution at scale. Serving the same file to thousands of recipients is the web's home turf — caching and content distribution infrastructure exists for exactly this. SFTP fan-out to large audiences is nobody's idea of fun.

Where SFTP Wins

Standardized batch semantics. Here is the cost of HTTPS that link-senders forget: HTTP standardizes the transport, not the file operations. Every HTTPS upload portal is its own little invention — different URLs, different form fields, different authentication, different success signals — so automating against one means custom work per endpoint, and that work breaks when the portal changes. SFTP standardizes the operations themselves. "Connect, cd /inbox, put nightly.csv, verify size, rename into place" is the same conversation against every SFTP server ever shipped. For unattended machine-to-machine transfer, that uniformity is worth more than any convenience feature.

Mature batch tooling. Decades of scripts, clients, and scheduling tools speak SFTP fluently: command-line clients with batch modes, graphical clients for the humans, libraries in every language, and dedicated automation products. Resume of an interrupted transfer is built into the protocol rather than being a design project — compare the engineering required to make large files over HTTP resumable. Directory listings, timestamps, and permissions are first-class citizens, so "fetch everything new since last run" is a naturally expressible job.

Partner expectations. In B2B data exchange, "we'll give you SFTP credentials and a folder" is the incumbent convention. Banks, insurers, logistics firms, payroll processors — their onboarding documents assume it, their operations teams monitor it, and their conventions (drop into /inbox, write as a temporary name, rename when complete so pollers never grab half a file) encode years of operational lessons. Proposing a bespoke HTTPS portal to such a partner often costs more negotiation than the integration is worth.

Machine identity done well. SSH key pairs give scheduled jobs strong, password-less, rotatable credentials — a solved problem with twenty years of operational practice behind it. Web-side equivalents (API tokens, client certificates) exist but arrive with more moving parts and less convention.

What Each Choice Quietly Gives Up

Choose HTTPS-only, and you give up uniform automation. Your scripted partners now integrate against your specific endpoint design; you own documenting it, versioning it, and keeping it stable, forever. You also sign up for designing your own answers to problems SFTP solved long ago: resumable transfer, atomic hand-off, directory conventions. None of this is prohibitive — well-designed file APIs handle all of it — but it is engineering you must do rather than inherit.

Choose SFTP-only, and you give up the zero-friction human experience. Every human participant needs a client, credentials they will mishandle, and a first-connection host-key moment they will not understand. Casual or one-time exchanges get heavy: nobody provisions an SFTP account to receive one PDF from an outside auditor. And where restrictive networks block non-web traffic, your service is simply unreachable.

Notice the shape of both paragraphs: each protocol's weakness is precisely the other's strength. That is why this decision resists a universal answer — and why the honest matrix below keys on the workflow, not the protocol.

The Decision Matrix

Find the row that matches the flow you are deciding, and take the third column into the meeting as your reason. When two applicable rows disagree, that is usually a sign one "flow" is really two flows wearing a trench coat — split them, and decide each on its own.

Three Flows, Decided

To see the matrix earn its keep, run three ordinary scenarios through it.

Collecting signed paperwork from job applicants. The far end is the general public: any device, no installable software, zero patience for instructions, and each person appears exactly once. Every factor points the same direction — an HTTPS upload page, reached by an expiring link in the offer email. Proposing SFTP here would be self-sabotage; the first applicant on a phone ends the experiment.

Nightly manifest exchange with a logistics partner. The far end is a program: their scheduler pushes a manifest at 2 a.m., your system returns confirmations. Their onboarding document specifies an SFTP host, an /inbox folder, and key-based authentication, because it specifies the same thing to every partner they have. Recurring, machine-to-machine, partner-mandated: SFTP three times over. Sign the form and set up the keys.

Field technicians fetching large firmware bundles on the road. The far end is a semi-technical human on whatever network the site offers — hotel Wi-Fi, a hospital guest VLAN, a client's locked-down floor. Only web egress reliably works from all of those, the recipients want a link and a progress bar, and the same bundle goes to many people. HTTPS — with resumable downloads enabled, since multi-gigabyte files on flaky links need the range-request treatment.

Three flows, three clean answers, and in each case the deciding vote was cast by the far end's constraints — not by anyone's protocol preference. That is the matrix working as intended.

The Realistic Answer Is Often Both

Look down that matrix with a real organization in mind and a pattern appears: the human-facing rows point one way, the machine-facing rows point the other — and almost every organization has both kinds of flow. The accounting partner's nightly batch wants SFTP; the auditor who needs to receive one folder of PDFs wants a browser link; the developer wants an API. Forcing every flow through one protocol means somebody's workflow is always wearing the wrong shoes.

This is why file transfer servers grew multi-protocol. Sysax Multi Server, to use ours as the example, serves HTTPS alongside SFTP, FTPS, and FTP from a single Windows install with one set of user accounts and one activity log — so the partner scripts speak SFTP, the humans click a browser link, and you administer one system instead of two. On the automation side, the scheduled SFTP legs of such a setup are exactly what Sysax FTP Automation exists to run: scheduled, scripted transfers with retry and error handling, no hand-rolled loops.

Running both is not a cop-out; it is the recognition that "which protocol?" was always really "which protocol for this flow?" The mistake worth avoiding is not running two protocols — it is running two whole disconnected systems, with two user databases and two logs, when one server could carry both.

A Ten-Minute Decision Procedure

For any specific transfer flow, walk these questions in order and stop at the first decisive answer:

THE TEN-MINUTE PROTOCOL DECISION
1. Is the far end a person or a program?
     person → lean HTTPS       program → lean SFTP
2. Can the far end install software and manage credentials?
     no → HTTPS (decided)
3. Does a partner standard or onboarding doc name the protocol?
     yes → follow it (decided)
4. One-off or recurring?
     one-off → HTTPS with an expiring link
     recurring → a real account, protocol per rules above
5. Must the audit log name the individual?
     yes → named accounts on either protocol; no bearer links
6. Multi-GB files over unreliable links?
     yes → SFTP's native resume, or budget chunked-HTTPS design
7. Does the transfer live inside a web app?
     yes → HTTPS (decided)
8. Still tied? → run both from one server; let each flow pick its door

Write the chosen answer into the flow's documentation with one sentence of reasoning ("HTTPS: recipients are external HR contacts with no IT support"). The next administrator — possibly you, later — will thank the record when the argument restarts.

The Version to Tell a Colleague

HTTPS and SFTP both encrypt properly; neither is the security choice. HTTPS wins whenever the other side is a human with a browser or a network that only speaks web: nothing to install, nothing blocked, links compose with email and portals. SFTP wins whenever the other side is a program: identical semantics on every server, key-based machine identity, native resume, and decades of batch tooling and partner convention. Give humans HTTPS, give machines SFTP, secure both, and when a flow could go either way, let the recipient's constraints — not your habits — cast the deciding vote.

To go deeper on the roads not fully taken here: the SFTP series covers that protocol end to end, presigned URLs covers the account-free HTTPS pattern, and building a safe internal file drop covers what it takes to stand up the HTTPS side responsibly yourself.

Frequently Asked Questions