File Uploads: Progress, Chunking, and Resumability

The plain-language idea

A single fetch with FormData is enough to send a file, but it leaves three real gaps a production upload experience usually has to fill:

• Progress — a plain fetch call gives you no upload progress events at all. This is a genuine, still-relevant limitation, not something fixed by a newer API: showing a real progress bar requires either XMLHttpRequest's upload.onprogress event, or a library built on top of it, because fetch historically doesn't expose upload progress the way XMLHttpRequest does.
• Chunking — splitting a large file into smaller pieces and uploading them separately, instead of one massive request. A single giant request is fragile: a mid-upload network drop loses the whole thing, and many servers enforce a request-size limit a large file can exceed outright.
• Resumability — if an upload is interrupted partway, a resumable protocol tracks which chunks already succeeded and only re-sends what's missing on retry, instead of restarting the entire file from byte zero. This matters most for large files on unreliable connections, like a mobile upload that drops mid-transfer.

Be honest about scope here: implementing chunking and resumability correctly — handling partial failures, verifying chunk integrity, resuming across page reloads — is real, nontrivial engineering, and most real products reach for an existing upload library or a managed upload service rather than hand-rolling the full protocol. The goal of this lesson is understanding why each piece matters and what problem it solves, not shipping a resumable-upload protocol from scratch.

See it in a real thing: progress via XMLHttpRequest, chunking by slicing the file

function uploadWithProgress(file: File, onProgress: (pct: number) => void) {
  return new Promise<void>((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    const formData = new FormData();
    formData.append("file", file);

    xhr.upload.onprogress = (event) => {
      if (event.lengthComputable) {
        onProgress(Math.round((event.loaded / event.total) * 100));
      }
    };
    xhr.onload = () => (xhr.status < 300 ? resolve() : reject(new Error(`Upload failed: ${xhr.status}`)));
    xhr.onerror = () => reject(new Error("Network error during upload"));

    xhr.open("POST", "/api/upload");
    xhr.send(formData);
  });
}

// chunking: split the file, upload each piece with its index so the server
// can reassemble it in order and retry just the pieces that fail
const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB

async function uploadInChunks(file: File, uploadId: string) {
  const totalChunks = Math.ceil(file.size / CHUNK_SIZE);

  for (let i = 0; i < totalChunks; i++) {
    const start = i * CHUNK_SIZE;
    const chunk = file.slice(start, start + CHUNK_SIZE);

    await uploadChunkWithRetry(chunk, { uploadId, index: i, totalChunks });
    // a real resumable implementation would persist "chunk i of uploadId
    // succeeded" somewhere durable, so a retry after a page reload can
    // skip straight to the first chunk that never got confirmed
  }
}

A large file is split into four chunks before upload begins, instead of sent as one giant request.

BackNext

What people usually miss

Watch out

• fetch giving no upload progress is a real, still-current limitation, not an old problem someone already fixed. Reaching for XMLHttpRequest (or a library wrapping it) specifically for the progress event is a legitimate, current reason to use it over fetch.
• Chunking alone doesn't give you resumability — it's a prerequisite for it. Splitting a file into pieces just makes each request smaller and more failure-tolerant per piece; actually resuming after an interruption requires the client (or server) to track which chunks already succeeded, which chunking by itself doesn't do.
• A request-size limit is a real, common reason chunking is necessary, not optional, for large files — a server or intermediate proxy rejecting a request outright above some size means a single giant upload isn't just slower, it can be structurally impossible.
• Retrying a failed chunk should retry just that chunk, not the whole file. The entire value of chunking for reliability is lost if a failure anywhere restarts the full upload from the beginning instead of just the failed piece.
• Hand-rolling full resumability is a real, nontrivial undertaking, and naming that honestly — rather than casually implying it's a small addition — is itself a sign of real experience with this problem.

Why this matters in interviews

"How would you handle uploading a large file with a progress bar that also survives a dropped connection?" is a real question that separates candidates who know fetch can't show upload progress and can name chunking/resumability as the actual fix for interruption, from those who only know the plain happy-path upload.