HTTP file transfer: how it works

HTTP file transfer is just moving a file between two machines using the same protocol your browser uses for web pages. You click a download link, that is an HTTP transfer. You drag a PDF into a web form, that is one too. If you have ever used WeTransfer, Google Drive or a "choose file" button, you have done it.

Most people never need to know more than that. But if you are picking a way to send files, building an upload form, or trying to work out why a download keeps dying at 94%, a bit of the plumbing helps. So here it is, without the textbook tone.

How HTTP file transfer actually works

There are two directions, and they work differently.

Downloads are the simple one. Your browser sends a GET request to a URL, the server answers with the file's bytes, and the browser saves or displays them. The link is the whole interface. That is why a URL is such a good way to hand someone a file: nothing to install, nothing to configure.

Uploads go the other way, usually as a POST request. When a form includes a file, the browser uses multipart/form-data. The MDN documentation on POST describes it as splitting the request body into parts, each separated by a boundary string, with a filename marking which part is the file. The browser sets all of that up for you. You only see a progress bar.

That is the entire trick. No special file protocol, just ordinary web requests carrying bytes.

Why big downloads can resume (and why some can't)

Everyone has had a 2GB download die near the end. Whether you can pick it back up comes down to range requests.

If a server sends an Accept-Ranges header with any value other than none, MDN's range request guide says it supports range requests. The client then asks for only the bytes it is missing, and the server replies with 206 Partial Content. A well-behaved client also sends an If-Range check, so it does not stitch half of an old file onto half of a new one if the file changed in between.

If the server doesn't support ranges, you get the whole file again from byte zero. That is why some links resume happily and others make you start over. It is a server setting, not something you can fix from your side.

If a download keeps restarting from zero on a flaky connection, the host is the first suspect. Switching to one that supports ranges is often the whole fix.

What HTTP is bad at

HTTP is great for a person sending a file to a person. It is a weaker fit for some jobs.

System-to-system, scheduled transfers. A nightly stock file between two companies usually goes over SFTP or something with retries, audit logs and credentials baked in. I covered that world in secure file exchange.
Very large files over unreliable connections. Plain HTTP uploads typically restart from zero on failure unless the service builds chunked, resumable uploads on top. Plenty do. Plenty don't. Check before you trust it with a huge file.
Moving files between two cloud services. Downloading to your laptop and re-uploading is slow and wasteful. There is a better route, which I walked through in cloud to cloud file transfer.

None of this makes HTTP a bad choice. It makes it the right choice for the ordinary case and the wrong one for the specialist case. Know which one you are in.

HTTP versus HTTPS: don't send anything over plain HTTP

This one is short because the opinion is short. Use HTTPS. Plain HTTP sends everything unencrypted, so anyone on the path can read or alter the file. For anything remotely private, an HTTPS link is the minimum, not a premium feature.

HTTPS only protects the file in transit, though. It says nothing about who can open the link afterwards. A link that works forever for anyone who finds it is a different risk, and I dig into it in direct link file sharing.

When a link beats an upload

For most documents, the real question is not "which protocol". It is "does the person receiving this need a file, or do they just need to read it?"

If they just need to read it, a file transfer is the wrong frame. Attaching a PDF or sending a download means it leaves your hands, gets saved somewhere, and tells you nothing. A managed link can keep it in one place, which means you can fix a typo after sending, and some tools report what happened to it. My quick guide on turning a file into a URL covers the mechanics, and PDF hosting covers picking where it lives.

This is where I'd mention what I build. LiveDocument lets you put a PDF or an image behind a single link and attach a video walkthrough to it, so the reader gets your voice as well as the file. You can set the link to expire or revoke it later, and you see page-level engagement. It is not a transfer tool for huge raw files or folders, not storage, and not a replacement for SFTP. If you need to move a 40GB project folder, use something built for that. If you need someone to understand a proposal, that is where it earns its place. There is a longer walkthrough at share a PDF as a link.

Frequently asked questions

Is HTTP file transfer the same as FTP?

No. FTP is a separate protocol built specifically for moving files, with its own commands and ports. HTTP is the web's general protocol that also happens to carry files well. For people, HTTP is easier. For automated, scheduled jobs, FTP's secure variants are still common.

Is HTTP file transfer secure?

Plain HTTP is not. HTTPS encrypts the transfer, which protects the file on its way. It does not control who can open the link afterwards, so think about expiry and who you give the link to.

Is there a file size limit for HTTP file transfer?

The protocol itself doesn't set a practical limit. The limits come from the server, the web form, the proxy in front of it and your connection. If an upload fails at a certain size, look at those before blaming HTTP.

Can an interrupted HTTP download be resumed?

Yes, if the server supports range requests. It tells the client so with an Accept-Ranges header. If it doesn't, the download starts again from the beginning.

The short version for Monday morning

Use HTTP file transfer for people, use SFTP for systems, and use a link when the person only needs to read the thing. Most of the time you were never really choosing a protocol anyway.

If you have ever sent something important into the void and wondered if it landed, that is the problem I built LiveDocument for. It lives at livedocument.com.