Summary

  • HTML's download attribute lets a page request a download and suggest a filename; the HTTP response and browser still have a say.
  • A 2013 Mozilla bug and a 2017 WHATWG discussion show why the apparently simple button grew a cross-origin border.

There is a tiny act of optimism in writing <a download="report.pdf">. The page has named the parcel before it reaches the door. A click should bring home a file called report.pdf, perhaps with the tidy satisfaction of a label printed in advance. The web, however, delivers the parcel through a second party: the server answering the request. And then a third party, the browser, has to put it somewhere on a real machine. Three hands reach for one luggage tag.

The server had its own vocabulary first. RFC 6266, published in June 2011, formalized HTTP Content-Disposition. A response may say attachment, prompting the save interaction, and may offer filename or the internationally capable filename*. The RFC describes these names as advice to the recipient. It gives the browser the unglamorous last-mile work: strip path components that might point at unintended directories, handle dangerous extensions, and keep special characters from turning a filename into a trap. A server can write “save this as”; it cannot grant itself permission to write into /etc/passwd by putting that path on the tag.

The HTML link then acquired a more direct request from the page. Chromium's own platform record lists a[download] at milestone 14. The attribute made a link express intent to download instead of navigate, and its value could suggest a local name. A publisher could present a useful “save the chart” action without rearranging the server response. The convenience was real. So was the question it carried: what happens when the file lives on somebody else's origin?

A Mozilla bug filed in 2013 captured the surprise in ordinary terms. A cross-origin image link with download="filename.png" opened the picture in Firefox while Chrome saved it. The reporter expected the two clicks to agree. Mozilla's reply called its behavior a necessary security measure and closed the report as invalid. That exchange is a good snapshot of a web platform argument: the site hosting the button can ask for a download, but the site hosting the bytes has its own role in how those bytes should be delivered.

By April 2017, a WHATWG issue laid out the split more precisely. Firefox and Safari then ignored the cross-origin attribute without an attachment response; Chrome downloaded but discarded the page's suggested filename. A standards editor observed that the specification allowed both outcomes and invited browsers to align. The difference lived in a narrow gap between download this resource and use this name. A site could persuade a browser to do one while losing the other. Meanwhile, WebKit's Safari 10.1 announcement presented anchor downloads, Blob files and suggested names as a new capability on macOS. The feature was useful enough to ship, awkward enough to keep debating.

The current HTML Standard states the bargain plainly. download signals the page author's intent. Its value recommends a filename, which Content-Disposition may override. In a cross-origin case, the standard calls for the server's attachment disposition so a page cannot quietly make another origin's content arrive as an unexpected file. The browser remains the person at the coat check: it reads the tag, checks the parcel, and chooses a safe place and name on the local system.

This small feature shows how much authority hides inside a familiar blue link. The publisher controls the button and can propose a name. The server controls the response and can propose another. The browser owns the final decision at the computer's edge. The luggage tag has room for several signatures; the one that matters most is the hand that actually puts the file down.