How File Upload Actually Works: From Browser to Server
Published 2026-04-24 · Updated 2026-06-09 · 8 min read · By the SENDIT team
A clear walkthrough of what happens between choosing a file and seeing an access code, and why uploads fail the way they do.
Uploading feels like a single action. Under the surface it is a sequence of half a dozen distinct steps, each with its own failure mode. Understanding the sequence explains almost every confusing upload error you have ever seen, and makes debugging your own transfers much faster.
Step one: selection
When you click a file input or drag a file into a page, the browser gives the page a reference to the file — not the contents. This reference exposes the name, size and type. Crucially, the page cannot read arbitrary files from your disk; it can only touch what you explicitly handed it. This is a fundamental browser security boundary and it is why a website cannot silently grab your documents.
Drag and drop works through the same mechanism with a different entry point. This is also where client-side validation happens: a well-built page checks size and type here and tells you immediately, before wasting your bandwidth.
Step two: the request
The file is packaged into a request, historically as multipart form data, which wraps the bytes with boundary markers and metadata so the server can separate the file from other form fields. The browser opens a connection over TLS and begins streaming.
Two things are happening simultaneously: your device is reading the file from disk, and the network is sending it. On a fast disk and a slow connection, which is the normal case, the network is the bottleneck and the progress bar is really a network progress bar.
Step three: why upload speed disappoints
Home and mobile connections are asymmetric by design. A connection advertised at 100 megabits per second may offer only 10 megabits upward. Uploading a one-gigabyte file on such a connection takes roughly fifteen minutes at best, and considerably longer in practice once overhead and contention are included. This is not the service being slow; it is the shape of consumer internet.
Mobile networks add variability. Signal strength changes as you move, and a handover between cell towers can reset a connection mid-transfer, which is why resumable uploads matter so much on phones.
Step four: server-side reception
The server streams the incoming bytes to temporary storage rather than holding the whole file in memory, which is why a well-built service can accept a file far larger than its available RAM. It then validates: is the size within limits, does the declared type match the actual content signature, does the request have a valid session or token.
Content-type validation is important and frequently misunderstood. The type the browser reports is a guess based on extension and is trivially forged, so servers inspect the first bytes of the file — the magic number — to determine what it really is.
Step five: storage and identity
Once accepted, the file is moved from temporary storage to permanent storage, given an internal identifier that has nothing to do with its original name, and recorded in a database along with its expiry time, size and any access secret. Encryption at rest, if the service uses it, is applied here.
The access code you receive is generated at this point: a short random value checked for collision against currently active codes, stored against the file record, and returned to your browser. It is deliberately not derived from the file, because a derived code would be predictable.
Step six: retrieval and expiry
On the receiving side, the code is looked up, checked against its expiry timestamp and its rate limit, and if valid the server streams the file back with headers instructing the browser to download rather than display it. When the expiry passes, a background job removes the object from storage and clears the record. A service that only marks the record inactive without deleting the object is doing half the job.
Common failures, explained
- Upload reaches 99 percent then fails: usually server-side size rejection or a proxy timeout, not a network problem.
- Upload restarts from zero: no resumable support, plus a connection interruption.
- File uploads but will not open: often a truncated transfer. Compare checksums to confirm.
- Works on desktop, fails on mobile: mobile browsers may suspend background tabs, killing the transfer.
- Type rejected despite correct extension: content signature did not match the extension, which is the validation working correctly.
Making uploads more reliable
Keep the tab in the foreground on mobile, prefer a stable connection over a moving one, disable sleep on laptops during long transfers, compress before uploading rather than after failing, and confirm with the recipient that the downloaded file opens correctly rather than assuming a completed progress bar means success.
Why resumable uploads matter
A plain upload is a single request: interrupt it and everything is lost. A resumable upload splits the file into chunks, uploads them individually, and records which chunks succeeded. If the connection drops at eighty percent, only the current chunk is repeated. On mobile networks this is the difference between a transfer that eventually completes and one that never does.
You can often tell whether a service supports it by watching what happens when you toggle airplane mode briefly during a large upload. If the progress bar resumes from where it was, chunking is in play. If it returns to zero, plan around it by using a stable connection for anything large.