When clicking a PDF link in Firefox and Chrome, the file will sometimes be opened for in-browser viewing and sometimes prompt a "Save as" dialog.
If I wanted to force the link to always prompt a download I could use the download HTML5 attribute.
However, I want to do the opposite. I.e., force the links to always be viewed in the browser.
Sort of an inverse download attribute. Is there such a thing? :)
I'd prefer to not modify response headers when serving PDF documents - I want to be able to specify in markup what the browser behavior should be.
Thanks!
You can achieve that by setting the appropriate header (for instance, in case of PDF, the header will be Content-type: application/pdf;
With this header, the browser will know the mime-type of the file and display it if it is compatible with it.
Here you can see the headers for a PDF.
As a hint, what I like to do is to use some sort of controller (in case you are using a backend language) that handles the download. Hence, to download myNewProject.pdf I do
<a href='download.php?file=myNewProject.pdf&viewInBrowser=1'>Download!</a>
Then I can set the appropriate headers depending on the file type, or if I want to force download or view it in the browser...
I'm using Firefox in XP. I went to the OPTIONS under Tools and found Portable Document Format. Click on it and it will allow you to change the way PDF files are handled.
open the file in a Microsoft Word and save as html.
Related
Update: I have concluded that this is a firefox issue. Chrome, Chromium Edge and Safari all work well with my solution. I have created a bug on the firefox bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1658877
I have a front-end that can download a file in 2 ways:
Click button 1 to open the file in the browser
Click button 2 to download the file to the hard drive
The way this works in the front-end is by using the <a download="FILENAME.EXTENSION"> tag and attribute for forcefully downloading the file, and to use <a> (without download) to make it open in the browser.
This works because the API never returns a content-disposition header (We use ASP.NET Core's File() method without the fileName parameter, which doesnt add a content-disposition header in this case) so the download attribute ensures it is downloaded.
Please read the background information before continuing
To try the fix the mentioned background information's issue, I changed our API to always return the following header for a file:
content-disposition: inline; filename=FILENAME.EXTENSION.
My idea is that the browser should open the file in the browser. if this is not possible, it will open a download pop-up and use the filename bit of the content-disposition header to give it a correct name. If it can open the file in the browser but the user pressed the download button, the <a download> should have higher priority and download.
The problem is that when using the <a download> way of downloading, that it STILL tries to open the file in the browser. I can understand why, but I would rather that it would respect the download attribute. I am using Firefox and the front-end and back-end run on the same domain!
Any clues?
For some background info:
We use ASP.NET Core 2.0. And if you use the built-in BaseController.File() method WITH the fileName parameter, it FORCES the attachment bit in a content-disposition header which makes it always download the file. We do not want that, so we used the variant of File() without specifiying a filename, which would not add a content-disposition header; this worked fine...
UNTIL we had to support MS word and MS excel files. When trying to use option 1, the user gets a pop-up like this:
As you can see, the filename is missing because the browser is not sending it in the content-disposition header. And I can't use the download attribute to specify it, because I pressed option 1 which means the file should be opened in the browser. If the file would be a PNG, it would then be forced to download.
At this point, I tried using inline;filename="FILENAME.EXTENSION as my content-disposition header, but this takes priority over the <a download> bit, defeating the purpose.
I can come up with 2 workarounds:
MS Word and MS Excel files must have a attachment bit in their content-disposition header so I can specify the filename and they download to disk, even if you tried opening it directly in browser.
But this isn't pretty; if some user would not have image/pdf support and downloaded an image or PDF file, my issue would still exist because the filename would be download again...
Have a download queryparam with the value 0 or 1 that specifies if the file should be downloaded with a INLINE or ATTACHMENT content-disposition header.
this might, compared to my current situation, be prettier, perhaps. but it is more work, and I wish that <a download> could just work.
I just want to know which file types (like .png, .pdf, .txt) can be viewed in browser (like Chrome, Firefox). Because sometimes when i click on file link, instead of displaying in browser it download automatically. Why this happens ? Below is my code. Any help will be appreciated.
<script>
function openPDF(url){
var w=window.open(url, '_blank');
w.focus();
}
</script>
<a href="burger1.jpg" target='_blank'>link</a>
<div onclick="openPDF('1.pdf');">PDF 1</div>
It indeed depends on several factors:
the server response Content-Disposition header value inline (open it) vs attachment
(classic download)
the browser configuration (how to behave for various file types)
installed browser plugins
the ability of the browser to open the file
A detailed technical explanation can be found here: https://superuser.com/questions/1277819/why-does-chrome-sometimes-download-a-pdf-instead-of-opening-it
For example Firefox can open most PDF files (but generally not advanced forms, encrypted files ...),
https://support.mozilla.org/en-US/kb/view-pdf-files-firefox
https://support.google.com/chrome/answer/6213030?hl=en
https://helpx.adobe.com/lu_en/acrobat/kb/open-in-acrobat-reader-from-chrome.html
https://www.investintech.com/resources/blog/archives/3684-view-pdf-files-mozilla-firefox.html (about browser PDF reading)
Most advanced PDF features will require the user of Acrobat Reader or a special Acrobat Reader plugin.
There are two aspects to this issue.
There are addons you can add on to the browsers to allow viewing virtually anything in the browser window. In the case of PDF, for instance Firefox can't show those by default, but you can install an addon. Or, there are standalone PDF viewers that also come with such an add-on which you can activate if desired.
And when you've done that, as noticed in the comments, if the resource is marked as download, the browser will download it instead of trying to open it, no matter the file type.
Ditto if it has a http header of Content-Disposition: attachment.
So don't use that.
In normal cases, following files can be viewed in browser.
.PNG
.JPEG
.PDF
.doc
etc ...
and following files will always be download.
.zip
.exe
etc ...
But in special cases, it depends on user browser settings and preference. You can get further details from this link.
A client wants a url to be a download link.
Use case is like so:
user gets linked to example.com/download once there, it downloads a pdf file.
Can I do this without php ?
HTML5 introduced the download attribute.
Supporting user-agents will offer to download the file foo.png when clicking this link:
<a href="foo.png" download>Save the image</a>
You can also specify a different default file name that should be used:
<a href="foo.png" download="image.png>Save the image</a>
Read more at http://www.w3.org/TR/html5/links.html#downloading-resources.
Note that this only works for links. When users enter the URL directly into their browsers, this will have no effect, of course. If you want that, you need to send specific HTTP headers. See for example the question: How to force download of a file?. You don’t necessarily need a programming language like PHP for that. You can do it with, for example, .htaccess, too: Force File(image) Download with .htaccess
How a file is displayed is browser specific. Some may force you to download while some directly render it on the browser.
If you want to force the browser to download the file then you can set in Header the
Content-Type : application/octet-stream
You only need a link (anchor tag). The way the link behaves on click will depend on what browser you are and what settings you have in that particular browser. Some browsers will prompt you to open or save the file, other browsers will open the PDF file on a new tab or window.
Download PDF
You'll also need to make sure that the path to the PDF file is correct on the href property of your anchor tag.
Use this (HTML) not PHP:
Download pdf
Use the full url including the pdf file like.
Download
In HTML, how do you link to a file that the browser can only download, not view? For instance, say I have a zip file, my-program.zip. I want visitors to my website to be able to download that file when they click a link. The link would look like this: download my program. On my webserver, the HTML file and the zip file are in the same directory, so the relative path of the zip file is simply its filename.
But if I just link to the file with an <a href="my-program.zip"> tag, the browser wouldn’t recognize the link, right? Because browsers can’t open zip files. So what is the proper way to link to it?
Actually, your example is the proper way to link to the file:
download my program
You can never tell for sure that a browser can’t view a file. You just link to it; it’s up to the browser to do what they think best with it – display it, download it, or do something else. Don’t worry; browsers will generally do the right thing.
This follows the principle of the web that you don’t know what the browser will do with the files and pages you send it. You mentioned a ZIP file, but think of PDF files. They are like a ZIP file: they are not HTML, they are not made for a browser, and the browser might download it. But there are plugins such as Adobe PDF Reader and Schubert’s PDF Browser Plugin that show the contents of the PDF file right in the browser. Similarly, hypothetically, there might be a ZIP file viewer for the browser – it might show the user the contents of the ZIP file in the browser and let the user decide where to extract those contents.
Most browsers don’t have the hypothetical ZIP file viewer described, so the file will just download, like you wanted. But that doesn’t really matter; just write your link and everything will be okay.
The browser could do things other than viewing the file or downloading the file right away. It could also ask the user if they want to download the file. Or it could start downloading the file, detect a virus in it, and delete it right away. The point is, it’s up to the browser what it does with the file.
Note that this policy goes the other way. Your HTML pages look to the browser just like files look – they are both “resources”. “Resource” is the “R” in “URL”. When you visit an HTML page by visiting a URL, the browser thinks “this is an HTML resource. What should I do with this? Oh, I can display it in the main window – I’ll do that.” This is the same process as downloading a ZIP file after clicking a link to its URL, where it thinks “this is a ZIP resource. What should I do with this? I can’t display it – I guess I’ll start downloading it and open the downloads window so the user can see what happened.” Most browsers even let you download the HTML of a page just like a file, if you ask it to.
If you have multiple formats of your file, and want to let the browser choose the best one it can view, then you could set up a system using the HTTP Accept header. For instance, if you had both a ZIP and a RAR version of my-program, then you could make it so you link to just my-program and the browser chooses the version it likes best. But the setup for that can be complicated, and that kind of system isn’t usually necessary for just a file download. The Accept header is usually used to get the correct version of something that the browser is meant to view – for instance, the browser might choose an MP4 video file over a WMV video file because it doesn’t have any codec that can play embedded WMV videos.
If you want to force the browser to download a file even though the browser can probably view it on its own, see this question.
I have an anchor tag that is used to request the download of a file.
Like this:
Download
The file may be modified on the server very often, so I want to make sure the browser does not cache the file.
However, testers found out that, although it seems to always download the file when you click on the link, when you right-click on the link and choose "Save As...", the browser seems to choose to use the cached file instead. This was tested with IE9.
How can I force the browser (especially IE9) to always download the file in every case?
I'll add as an answer. Try adding a random number to the query part of the href:
?param=[random]
As per my own comment for one of the answers:
According to wikipedia I can set the response header parameter: Cache-Control: no-cache
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Effects_of_selected_HTTP_header_fields
After receiving a response with this header, the browser will not cache this data anymore.