When you download a file, the browser does not copy a finished object straight into your Downloads folder. It makes a network request, reads response headers, streams bytes into temporary storage, runs safety checks, and only then commits the file to the location you chose.
That extra care matters because a downloaded file leaves the tab. It can be opened by another app, shared, executed, backed up, or mistaken for a trusted document later. A broken web page can be reloaded. A broken file can stay on disk.
The download starts as a request
Most downloads begin with one of these actions:
- clicking a link to a file
- clicking a link with a
downloadattribute - submitting a form that returns a file
- running JavaScript that creates a
Bloband triggers a save
For a server file, the browser sends an HTTP request like it would for a page, image, script, or API response. The difference is what happens after the response headers arrive.
For a local file generated by JavaScript, there may be no network request at all. A browser tool can create a Blob, attach it to an object URL, and ask the browser to save it:
const blob = new Blob([text], { type: "text/plain" });
const url = URL.createObjectURL(blob);
const link = document.createElement("a");
link.href = url;
link.download = "notes.txt";
link.click();The file still goes through the browser’s download handling, but the bytes came from code already running on the device.
Headers tell the browser what the file is
The server describes the response with HTTP headers. Two of the most important are Content-Type and Content-Disposition.
Content-Type: application/pdf
Content-Disposition: attachment; filename="report.pdf"Content-Type tells the browser what kind of data arrived. application/pdf, image/png, text/csv, and application/zip all lead to different handling.
Content-Disposition: attachment tells the browser to treat the response as a download instead of trying to display it inline. The optional filename value suggests the saved name.
If Content-Disposition is missing, the browser uses fallback rules. A PDF may open in a tab. An image may display directly. A file type the browser cannot render may download. That is why the same kind of file can open on one site and download on another.
The file streams in chunks
A download is a stream of bytes, not one giant value. The browser starts receiving chunks as the network delivers them.
Streaming avoids a memory problem. A 2 GB video cannot sensibly sit in a tab’s JavaScript memory before anything happens. Instead, the browser writes incoming chunks to temporary storage while it tracks how much has arrived.
This is also why cancelling a download can stop the transfer without leaving a finished file behind. The final file has not been committed yet.
Progress depends on Content-Length
A progress bar needs two numbers: bytes received and total bytes expected.
Servers often provide the total with Content-Length:
Content-Length: 73400320The browser can then calculate:
progress = received bytes / content lengthWhen the server does not send a reliable length, the browser can show that data is arriving, but it cannot show an accurate percentage. The file may still download correctly. The browser just does not know the finish line in advance.
Temporary files protect the final copy
Browsers usually keep in-progress downloads in a temporary location or with a temporary name. The visible file is finalized only after the transfer finishes.
That separation protects the final copy from partial data. If the connection drops after 43 MB of a 70 MB file, the browser can discard the incomplete data or offer a resume option. It does not have to leave a corrupt file with the final name.
Finalization may include:
- moving or renaming the temporary file
- applying the final filename
- marking the download as complete in browser history
- handing the file to the operating system’s file manager or opener
Resume support is a server feature
Some failed downloads resume from the last byte. Others start over.
Resume depends on byte-range requests. The browser asks the server for a slice of the file:
Range: bytes=43000000-For that to be safe, the server must support ranges and the file must still be the same version. If the server cannot guarantee that, starting over is safer than stitching together mismatched pieces.
HTTPS protects the trip, not the file’s intent
HTTPS encrypts the connection and helps prevent the file from being read or changed in transit. It does not prove that the file itself is harmless.
A malicious executable can be delivered over HTTPS. So can a spreadsheet with dangerous macros or a ZIP containing unwanted files. Transport security answers one question: did the bytes arrive from the server without network tampering? It does not answer whether you should open them.
Safety checks before and after the save
Browsers and operating systems apply extra checks around downloads, especially for files that can run code or affect the system.
Those checks may include:
- comparing the extension with the detected file type
- warning about executable formats
- checking reputation or known-dangerous downloads
- blocking silent or repeated downloads without user intent
- marking the file so the operating system can warn on first open
A warning does not always mean the file is malicious. It means the browser cannot treat the action as routine.
DevTools shows the network part
You can inspect many downloads in DevTools:
- Open DevTools.
- Go to the Network panel.
- Start the download.
- Select the request.
The request can show the URL, response headers, status code, transfer size, and timing. For a large download, the waterfall stays open while bytes keep arriving.
DevTools does not show every local filesystem detail. Temporary file names, operating system quarantine flags, and final file movement happen below the network layer.
What the browser has decided
By the time the file appears in your Downloads folder, the browser has answered several questions:
- Should this response render in the tab or save as a file?
- What filename and type should be used?
- Is the transfer complete?
- Can the download resume if interrupted?
- Does the file need a warning before the user opens it?
A download is the handoff between the web and the operating system. The browser is careful because that boundary is where bytes become a file you may trust later.
