What Happens When You Upload a File?

Clicking 'Upload' looks simple, but behind the scenes your browser slices, packages, and streams data through one of the web’s most complex handshakes. Here’s what really happens when you send a file - and why modern browsers make it faster and safer than ever.

Sun Oct 12 2025 • 8 min read

Every day you upload something - a photo, a form, a résumé, a design draft. You click a button, see a progress bar, and assume the rest is automatic.

But that single moment hides a lot of invisible engineering. Your browser is reading your file system, creating a secure reference, slicing data into pieces, and streaming them across the network - all while keeping the rest of your computer off-limits.

Uploads feel effortless because the browser handles the complexity for you. Here’s what’s really happening when that bar starts to fill.

---

Selecting the File

When you click Upload or drag a file into a drop zone, your browser doesn’t hand the entire file system to the website. It only exposes the specific file you choose, wrapped in a secure container called a File object.

• The operating system gives the browser a temporary handle to that file.
• The browser reads metadata like name, size, and MIME type.
• The page cannot explore folders, subdirectories, or other files.

Even drag-and-drop uses this same model - the browser receives a FileList, not a directory listing.

If you select multiple files, each one becomes its own secure object. And when you close the page, those references vanish. The website never gains long-term access to your disk.

Important: The browser never reads the entire file until you choose to upload or preview it. Until then, the reference is just a pointer - like holding a ticket, not the movie reel.

---

Turning It Into Data

Once you’ve chosen a file, your browser must convert it into a form the web understands. The most common method is multipart/form-data - the standard encoding for web forms.

Here’s what happens under the hood:

1. The browser creates a unique boundary marker, such as ----WebKitFormBoundary12345.
2. It wraps each field and file between these boundaries.
3. Each section gets headers describing its content type and name.
4. The file’s raw bytes are streamed between these headers.

A simplified version looks like this:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary12345

------WebKitFormBoundary12345
Content-Disposition: form-data; name="username"

john
------WebKitFormBoundary12345
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg

(binary data here)
------WebKitFormBoundary12345--

That’s the invisible envelope your browser builds before sending data across the network.

Large files don’t travel as a single blob - they’re sliced, encoded, and streamed in pieces. That’s why a 1 GB video might show progress in waves: each chunk is being prepared, uploaded, acknowledged, and followed by the next.

---

Sending It Across the Network

Once packaged, the browser opens a secure connection to the target server using HTTPS - which runs over TLS-encrypted TCP (or QUIC for HTTP/3).

How HTTPS Ensures Security and Reliability

HTTPS combines two critical layers:

• TLS (Transport Layer Security) encrypts your data end-to-end. Before any file bytes leave your computer, the browser and server perform a “handshake”: they exchange digital certificates, agree on encryption algorithms, and generate session keys. This creates a private tunnel - even if someone intercepts your packets, they see only encrypted gibberish.

• TCP (Transmission Control Protocol) underneath handles reliable delivery. It breaks your file into numbered packets (typically ~1-64KB each), sends them across the network, and waits for acknowledgments (ACKs) from the server. Lost packets get automatically resent; out-of-order packets get reassembled. This guarantees your file arrives complete and uncorrupted.

The result? Your upload is both private (TLS encryption) and reliable (TCP guarantees), even over spotty Wi-Fi.

Modern Protocols: HTTP/2 and HTTP/3

Most browsers now use HTTP/2 or HTTP/3 for uploads, building on that TLS+TCP foundation:

• HTTP/2 enables multiplexing - multiple upload streams sharing one TLS connection, reducing setup overhead.
• HTTP/3 (built on QUIC) goes further: it uses UDP instead of TCP for faster handshakes and better mobile performance, while maintaining the same encryption guarantees.

These protocols turn your single progress bar into a sophisticated operation: thousands of micro-packets flowing in parallel, prioritized by the browser, with rapid recovery from network hiccups.

---

Tracking Progress

Browsers continuously measure how much data has been sent and how long each packet takes to be acknowledged.

When you see “54% uploaded,” the browser isn’t guessing - it’s counting bytes:

• Total file size from metadata.
• Bytes successfully acknowledged by the server.
• Time remaining, estimated by throughput and latency.

Web APIs like XMLHttpRequest and fetch() with streams expose progress events, allowing sites to show smooth upload bars or estimated times.

const form = new FormData();
form.append('file', myFile);

fetch('/upload', {
method: 'POST',
body: form,
}).then(r => console.log('Done!'));

With ReadableStream support, the browser doesn’t even need to buffer the entire file - it can send it piece by piece while still reading from disk.

---

Smarter Uploads with Modern APIs

Over the years, uploads have evolved from simple form submissions to sophisticated workflows powered by new browser APIs:

• FormData API - packages text and files in one unified structure.
• Fetch with Streams - uploads data progressively without freezing the UI.
• FileReader & Blob APIs - preview, resize, or compress files locally before sending.
• Web Workers - offload heavy tasks (like ZIP compression) to background threads.

For example, when you upload a photo and instantly see a thumbnail, that image never touched a remote server. Your browser created it locally using [FileReader](https://developer.mozilla.org/en-US/docs/Web/API/FileReader) and [Canvas](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API) - then displayed it, all within your device’s memory.

That’s local-first design in action: private, fast, and efficient.

---

Security and Privacy by Design

The upload process is one of the most carefully sandboxed features in the browser.

• A page can’t read files you didn’t explicitly select.
• It can’t access parent folders, hidden files, or metadata beyond what’s exposed.
• Temporary handles are discarded when the tab closes.

Even when you drag a file into a web page, the browser intermediates that gesture through a [DataTransfer](https://developer.mozilla.org/en-US/docs/Web/API/DataTransfer) object - not direct disk access.

Sandbox rule: The website never touches your actual filesystem. The browser is the courier, not the vault.

Only after you confirm the upload does your data leave your computer - and even then, it’s encrypted via HTTPS, chunked into packets, and routed safely to the target server.

---

The Local-First Alternative

Not all uploads need to travel across the internet.

For many workflows - image conversion, text extraction, compression - your browser can do the job itself. Using the same File APIs, tools like Vayce Image Converter can open, process, and save files entirely within your browser.

const reader = new FileReader();
reader.onload = e => console.log('File data:', e.target.result);
reader.readAsArrayBuffer(file);

That’s the same core technology used for “upload,” just without the network step.

This model has clear benefits:

• Instant performance (no waiting for server responses).
• True privacy (data never leaves your device).
• Simplicity (no backend storage or bandwidth costs).

Your browser isn’t just a viewer anymore - it’s a capable local runtime.

---

How to See It in Action

You can observe a live upload from inside your browser - no special tools needed.

1. Open DevTools → Network tab in Chrome, Firefox, or Edge.
2. Visit any site that allows file uploads (or a local test page).
3. Start an upload and watch the network request appear.

You’ll see:

• The multipart/form-data structure with boundaries.
• Real-time packet timing and throughput graphs.
• The exact response once the upload completes.

For a quick script-based experiment, you can log progress with JavaScript:

const xhr = new XMLHttpRequest();
xhr.open('POST', '/upload');
xhr.upload.onprogress = e => {
    const percent = (e.loaded / e.total * 100).toFixed(1);
    console.log(`Progress: ${percent}%`);
};
xhr.onload = () => console.log('✅ Upload complete!');
xhr.send(new FormData(document.querySelector('form')));

As data flows, your browser continuously emits progress events - translating raw byte counts into something human: the progress bar filling in real time.

---

Why It Matters

Uploads might seem ordinary, but they represent one of the web’s most complex - and impressive - collaborations between your operating system, browser, and network stack.

Every time you drag a file into a window, the browser:

• Mediates access between your device and the web.
• Translates the file into a web-safe format.
• Streams it securely and efficiently through multiple network layers.

Understanding that process helps you appreciate just how much power lives inside your browser.