That distinction matters when a web app offers both “open original” and “download ZIP.” The first action can navigate to a resource. The second needs to fetch its contents, collect the bytes, and build an archive. A successful navigation does not establish permission for that cross-origin script access.

Disclosure: I work on SiloSave. This engineering note was prepared with AI assistance and checked against our browser ZIP implementation and the documentation linked below.

Separate the two paths

Think of the interface as two independent operations:

1. Open an original file: let the browser navigate to the source URL.
2. Build a ZIP: use JavaScript to read every selected response body, then pass the bytes to an archive writer.

The second path depends on the remote server's cross-origin response policy. An image displaying successfully in a tab is therefore an incomplete test of a ZIP feature. MDN's CORS guide explains how servers grant cross-origin script access through response headers.

Do not replace a failed CORS request with no-cors

Changing a request to mode: "no-cors" can look tempting when a cross-origin fetch fails. It does not give an archive writer readable bytes. The resulting opaque response hides the body and headers from JavaScript. See MDN's Fetch response types.

A small, illustrative fetch boundary can look like this:

async function readPublicFile(url) {
  const response = await fetch(url, {
    mode: "cors",
    credentials: "omit",
    referrerPolicy: "no-referrer",
  });
  if (!response.ok || response.type === "opaque") {
    throw new Error("File response is not readable");
  }
  return new Uint8Array(await response.arrayBuffer());
}

This is only the read boundary. It is not a complete downloader: it does not include a URL policy, cancellation, size limits, retries, or ZIP generation. It assumes a public resource that does not require credentials; omitting credentials will not make authenticated files available.

Treat size metadata as a hint

Our ZIP builder can request declared sizes before downloading the bodies. That can reject an obviously oversized selection early. But a failed HEAD request, a missing length, or a different GET response still has to be handled.

Check the bytes actually read as well. A missing size is unknown, not evidence that a file is empty.

There is another limit to keep visible: checking arrayBuffer().byteLength happens after that body has been buffered. It can enforce an acceptance rule, but it is not a hard limit on peak browser memory. The source arrays and the generated archive can also coexist. A streaming design needs its own cancellation and memory tests.

Keep filenames and progress honest

Two files with the same proposed name can overwrite each other in a filename-keyed map before the ZIP is generated. Allocate a unique archive name for each file, such as photo.jpg and photo-2.jpg.

Separate the “reading files” and “building archive” phases in the progress display. Reaching the last network response is not the same as having a downloadable archive ready.

Offer a useful failure path

If a batch cannot be read, preserve the source information and the individual original links when those are available. Explain that the browser could not build this ZIP. Do not automatically label the original post as deleted or private.

A rejected fetch alone also does not prove CORS was the cause. Network failures and browser restrictions can produce similar symptoms; inspect the console and network details when diagnosing the specific failure.

For our product's accepted URLs and browser export limits, we maintain a Threads compatibility reference. The general design lesson is to represent direct navigation and script-readable downloads as separate capabilities.

Before shipping, test a readable response, a rejected fetch, an oversized declared response, duplicate names, and progress transitions. Mocked unit tests can check your handling of these cases. A real browser test against two origins you control is still needed to verify actual CORS enforcement.