A Web Link Can Download on One Site and Open on Another
Adding the HTML download attribute does not give a page universal control over every file it links to. A link to a file served from the page's own origin can behave differently from a link to the same kind of file on another origin. The receiving browser and the file server also influence what happens.
That is why a button labeled “Download notes” may save a file during one test but open a document after its destination changes. Before rewriting the button or blaming the hosting platform, separate three things: the link's markup, the address that supplies the file, and the response that address returns.
Follow the file when a familiar link changes behavior
Consider a fictional astronomy club whose volunteer, Leon, maintains a small public information page. A plain-text observing checklist lives beside the site's other files. The club's link requests a download, and Leon's browser saves it.
Later, a partner organization hosts the checklist. Leon updates the destination but keeps the wording and the download attribute. Now his browser displays the text instead. The visible link looks unchanged, but the request no longer goes to the same origin.
This is a useful starting point because it limits the investigation. The question is not whether the page can ever offer downloadable material. It is whether the previous behavior depended on where this particular file was served.
Write down what changed: destination address, file type, server configuration, or browser. If several things changed together, test them separately rather than treating the whole page as one broken component.
Also record the actual result. A file opening in a browser tab is different from a failed request, a sign-in screen, or an error page saved with a familiar filename.
Check the origin, not the organization name
For ordinary web addresses, an origin is defined by the scheme, hostname, and port. Matching artwork, shared ownership, or a similar domain name does not make two addresses the same origin.
A file under another path on the same origin is different from a file hosted on another subdomain. Two local test servers using different ports also have different origins. These details matter even when the content itself is identical.
For ordinary HTTP or HTTPS links, the download attribute is limited to same-origin destinations. Browser-generated blob: and data: resources are separate supported cases; they are not a reason to assume arbitrary external links work the same way.
A relative file path is often convenient for a same-origin download. However, inspect the actual request if a redirect is involved. A path that starts locally can lead somewhere else, and the address written in the HTML is not always the final file destination.
For Leon's club, the useful comparison is between the page's origin and the origin serving the checklist. Comparing the names of the two organizations would not answer the technical question.
Use the attribute to express an intention
A simple same-origin example could look like this:
<a href="/files/observing-notes.txt" download>
Download observing notes
</a>
Here, the path identifies a file and the attribute requests download handling. The wording describes that intended action, but the presence of the attribute alone is not proof that a successful download occurred.
The attribute can also suggest a filename:
<a href="/files/observing-notes.txt" download="club-notes.txt">
Download observing notes
</a>
Treat that name as a suggestion, not a guarantee of the final saved name. Browser handling and response information can affect the result. Giving a resource a different extension also does not convert its contents into that format.
The examples assume the file exists at the shown path on the deployed origin. They are illustrative markup, not a working download embedded in this article. A correct attribute cannot compensate for a missing file.
When reviewing a change, inspect the destination and the attribute together. It is easy to preserve the second example's friendly label while moving the file to a service with different behavior.
Do not “fix” the situation by adding more emphatic text such as “Download immediately.” A label is communication for the reader, not an instruction that overrides browser behavior.
Ask which server controls the response
The server returning a file can send a Content-Disposition response header. An attachment disposition tells the browser to handle the response as a download, while inline indicates that it may be displayed within the browser.
This is separate from the attribute on the page containing the link. If a partner hosts the file, changing your page's HTML does not change that partner's response headers.
For Leon, there are three practical options. Keep an authorized copy on the club's own origin, ask the partner whether it provides an intended download endpoint, or describe the external link as opening the checklist. The choice depends on ownership, update responsibilities, and what the partner supports.
When looking for the appropriate resource page, a reference such as 주소가자 사이트모음 can be an additional discovery point. Verify the final destination and the publisher's file instructions independently; the reference does not establish a download guarantee.
Avoid copying someone else's file onto your site solely to regain a particular button behavior. Confirm permission and decide who will keep the copy current. A predictable interaction is not useful if it delivers an unauthorized or outdated document.
If you control the file server, inspect its response before changing configuration. If you do not, choose wording and instructions that fit the behavior you can actually support. Neither approach requires promising that every browser will show an identical save dialog.
Test the reader's action and the resulting file
A useful test begins from the page a reader will visit, not by opening a file directly from your computer. Local file viewing and an HTTP-served page are different situations.
Use an ordinary click or keyboard activation, then observe what happens. Was a download reported by the browser? Did navigation occur? Did the destination require authentication? Was the expected content returned?
A small acceptance checklist keeps these questions separate:
- Open the intended page in the browser being tested.
- Confirm the destination currently attached to the link.
- Activate the link and record whether it downloads or navigates.
- If it downloads, locate the completed file and inspect its contents.
- If it opens, confirm that the reader has reached the intended document.
- Repeat in the other browser or device you intend to support.
Check the file itself, not just its name. A saved sign-in page is not the observing checklist, even if the download appears in the browser's history.
Keep the test conditions with the result: browser, page address, destination, and date. A successful desktop check is evidence for that setup, not proof of every mobile or managed-browser configuration.
For a controlled comparison, a maintainer can serve identical harmless text from two local origins and compare it with an attachment response. That isolates the mechanism without repeatedly downloading large files or experimenting against someone else's server.
A test can establish that your chosen flow works in the tested environment. It cannot force a reader's download settings or determine where that reader later moves the file.
Questions to settle before calling the link reliable
Does a different subdomain count as the same origin?
No. A different hostname means a different origin, even when both addresses belong to the same organization. Compare the scheme, hostname, and port rather than assuming that related branding makes the download attribute apply.
Can an external file still download?
Yes. A cross-origin destination can return a response intended as an attachment, or other browser handling may lead to a download. The important distinction is that adding download to your link does not universally impose that behavior on the external server's file.
Should the label say “Open” instead of “Download”?
Use wording that matches the flow you have verified. If the supported behavior is to open a document page, say so and provide any necessary saving guidance nearby. Do not describe a navigation as a guaranteed automatic save simply because that was your original intention.
For the astronomy club, the reliable outcome is a clear route to the correct checklist, with tested behavior and honest wording. Check the file's origin and response before changing the presentation. A familiar-looking link can cross a technical boundary even when its label never changes.