Chrome Download Attribute not working

I've experienced some unexpected behavior of Chrome since the newest version: While in Firefox this Code is working Perfectly fine:

<a id="playlist" class="button" download="Name.xspf" href="data:application/octet-stream;base64,PD94ANDSOON" style="display: inline;">Download Me</a>

It isn't working in Chrome (Simply downloading a file named "Download"), but has worked pretty fine before. What do I have to change that it is working again?

152416 次浏览

After some research I have finally found your problem.

<a> download attribute:

If the HTTP header Content-Disposition: is present and gives a different filename than this attribute, the HTTP header has priority over this attribute.

If this attribute is present and Content-Disposition: is set to inline, Firefox gives priority to Content-Disposition, like for the filename case, while Chrome gives priority to the download attribute.

Source

HTTP-Header Content-Disposition

Reading the comments, I had the same issue as @buffer-overflow and found this in the issue:

I'm guessing that the web page and the download are on different origins. We no longer honor the download attribute suggested filename for cross origin requests. Clicking on the link still initiates a download. But the the filename is only derived from factors solely dependent on the server (e.g. Content-Disposition header in the response and the URL).

So no chance I could make it work ... :(

Go To Chrome Click on “Settings” and you'll see a new page pop up in your Chrome browser window. Scroll down to Advanced Settings, find the Downloads group, and clear your Auto Open options. Next time you download an item, it will be saved instead of opened automatically.

This can be resolved by adding target="_blank" attribute to the href.

Like this:

Save sprites.svg as
<a target="_blank" download="somefilename.svg"
href="https://cdn.sstatic.net/Img/unified/sprites.svg"
>somefilename.svg</a>

I have a simple solution regarding this issue. You just need to put your html file into a server like Apache using xampp control and so on. Because the download attribute is properly working through a server.

<a download href="data:application/octet-stream;base64,PD94ANDSOON">Download Me</a>

Are you looking at the files via a web server or your local filesystem - Does the browser's URL bar start with http:// or file:///? I just ran some tests in Chrome, and while it will download the file, it doesn't respect the value of the download attribute when you're using the local file.

If you start hosting it on a web server, this will start working. If you're just doing this for yourself on your computer, check out WAMP for Windows or MAMP for macOS to get started with Apache.

I recommend using the file-saver NPM Package to implement or force download.

// 1.
npm i file-saver // install via npm or
yarn add file-saver // install via yarn


// 2.
import { saveAs } from 'file-saver'


// 3.
saveAs('https://httpbin.org/image', 'image.jpg')

References

I had this problem with wordpress, the problem is that wordpress generates the full path of the file, and in the a tag you have to remove the full domain name and add a relative path

Example, instead of:

<a href="http://mywordpresssite.com/wp-content/uploads/file.mp4" download="file.mp4" >

You have to do this:

<a href="/wp-content/uploads/file.mp4" download="file.mp4">

This will make it work

It won't work without a server. download attribute will do the work only when using a server (local/remote) like tomcat/xampp/wampserver...

<a href="videos/sample.mp4" download>Download Video</a>
<a href="images/sample.jpg" download>Download Image</a>

Not just only for videos or images.

This is the current behaviour in Chrome as of 16 Aug, 2021

If you are calling an api like this: http://localhost:9000/api/v1/service/email/attachment/dummy.pdf

Chrome will try to parse the last value of the path param and ignore any value passed to attachment attribute of a link if Content-Disposition is not set or is set to inline from the server, in which case the pdf file will have the name dummy.pdf

If Content-Disposition is set to attachment, then chrome will save the file with the filename value from Content-Disposition header.

That is if the server were to respond like this:

res.setHeader(
"Content-disposition",
"attachment; filename=" + "server-dummy.pdf"
);
res.setHeader("Content-Type", "application/pdf");

The file would be saved as server-dummy.pdf regardless of the presence of download attribute.

The file has to be in some zipped format!