Open pdf in Browser not SharePoint pdf Viewer

Iron Contributor

When I click on a pdf file either in search results or the document library web part the file opens in the web browser. When I put a link to the same file in an image web part the file opens in the SharePoint pdf viewer. 

 

Is there a way to change the default or disable the SharePoint pdf viewer so that clicking on a link to a pdf will always open in the web browser?

 

It normally wouldn't make a difference but there appears to be a bug in the SharePoint pdf viewer that doesn't recognize all hyperlinks. They show in blue but there is no link. We have a pdf with many hyperlinks to other documents on the SharePoint site. When the pdf is opened in a web browser all the hyperlinks work correctly.

 

If anyone is curious how to make the hyperlinks fail in the SharePoint viewer here is what we did. We created a Word document and set the hyperlink base to be a SharePoint Document Library. In the document there are various hyperlinks - some to external sites and some to filenames in the Document Library. The Word document was saved as a pdf. The pdf was opened in Adobe reader and all the links - both external and SharePoint worked. We uploaded the pdf to SharePoint. If the file is opened in the web browser all hyperlinks work. If it is opened using the SharePoint pdf viewer only the external links work. The links to files in the Document Library don't. 

 

If we could just get rid of the SharePoint pdf viewer everything would work fine since everyone's web browsers can view pdf files.

18 Replies

@John Twohig 

Hello,

For security reasons, SharePoint prefers to open PDF files, especially with a hyperlink through SharePoint PDF viewer. Syncing the Document Library and open the PDF file from the computer may resolve this.

I know it's bothering many users but SharePoint trying to keep the environment safe.

 

Hope this resolve the issue 🙂

 

@Alireza Rahimifarid 

 

No. That can't be true. Otherwise, they would not allow the Open in Browser option at all and it wouldn't be the normal behavior when clicking on a pdf from search results or from the Document Library Web Part.

Yes I have also found this very annoying...we have a system which is fronted by a Visio diagram on the home page...the links from the visio shapes open the pdf documents in full web browser mode.

 

Where as the quick links web part underneath only open the pdfs in the sharepoint web viewer and we don't want our users to see version history for a start (thats for the Quality control team only) but actually more importantly the sharepoint pdf viewer displays the full A4 page in the window, and its difficult to read whereas Id prefer the full browser view as it fits the page by width and you can actually read the content.

 

You would that that there being a different URL for standard open and the web browser open the link should work for each type of experience. It's baffling.

 

 

 

@John Twohig 

@Darren Graham This also has user experience implications: consider a Sharepoint communications site with links to various PDF documents. When you link to those documents using the Quick Links webpart and the site opens them using the SharePoint pdf viewer, the viewer puts its own toolbar up. One of the options on that toolbar is a "close" cross. Hitting that cross does not back you out to the page, rather it just closes the document and dumps you into the directory the PDF sits in, which the user may never even have seen before and certainly might not be familiar with.

This is very bad from a UX standpoint, and even just a URL modifier that I could manually append to each Quick Link to use the browser's own PDF viewer would be helpful.

@LeeUnderwood 

Has this been resolved?  I have a link to a PDF for students.  When they close the documents, it opens up the document library.  I need the window close instead.  The way it works now is illogical.  

@KDRUIS 

No, the behaviour is still active for me.

I am also having an issue with the SharePoint PDF viewer. It does not print a PDF. Instead, clicking Print just opens the PDF again in the SharePoint PDF viewer on a new browser tab and does not bring up the print dialog. As a workaround the user has to click "Version History" from the SharePoint PDF viewer and then select the latest version. This opens it in a new browser window in Adobe Reader, from where the user can print.

This is not the behaviour at my other customers. Their SP sites open PDF files in Adobe Reader and can print without an issue. This leads me then to think that there must be a setting somewhere that controls this behaviour.

@MicrosoftSupport, can you please look into this and provide a response? the response provided by Alireza is not sufficient.
Still active also for me, and very frustrating.
Any solution? Openng a pdf from a SP site is such a basic navigation scenario!

@John Twohig 

We too are not happy with the lack of functionality. We have a PDF of a word document, which contains a table.  When the pdf is opened in sharepoint, we are unable to search the table in the pdf! When you open in the browser, we can search the document, and hit the table.  It is very frustrating that we have to open, then open in browser, to obtain search functionality.

@John Twohig @jm_herard @LeeUnderwood @NanetteDV @KDRUIS 

Not a fix but more a workaround. The issue is specific to the QuickLink web part. For PDFs it adds a ?web=1 to the end of the address forcing the PDF to open in the SharePoint PDF viewer. I thought the solution may be to use #page=1 to force it to open in the browser, but the web modifier it adds overrides the page modifier.

My solution, was to load the address (https://organization.sharepoint.com/sites/SiteName/LibraryName/Portable%20Document%20Format.pdf) into a URL shortener like bit.ly or tinyurl.com then use the generated link (https://bit.ly/[whatever]) in the QuickLink web part. That worked for me.

 

Thats a great workaround especially for the Quicklinks webpart.

A more useful application for us on Modern Pages would be to use the Highlighted Content webpart to pull through from our mass library the documents which meet certain criteria and this could be list of several pdf files. Opening pdfs from highlighted content also open in the sharepoint pdf viewer rather than full in browser mode. The 2 main issues we have with the sharepoint viewer is the top banner providing version history. We don't want our employees being able to access previous versions of documents for fear of misuse (ISO 9001 document control) and secondly the display can be small. Full browser mode A4 pages open up full width, sharepoint mode we need to zoom in a bit.

There is one solution I see here and that is a simple toggle setting in the library settings for how pdfs should open by default and it doesnt matter if its a quicklinks webpart, highlighted content, image webpart sharepoint knows its a pdf and will open the document in one default mode for that library.
Yes "if only we could get rid of the previewer"!!!
I agree - the issue of the previewer showing the full page is annoying, plus links to parts of the document do not work. Users have to actively select to open in browser or download the document to open in Adobe, but users do not know how. you can spend time making a great interactive training or information resource in PDF but users just see a basic document. With writing that's too small to see, We need to able to disable the previewer for users.
if I'm sharing a link to something, for example in an email, I tend to delete everything in the URL after ".pdf". Then it should open in the browsers. But if a person is on a SharePoint and selects a document to open, it will always be in the previewer and i don't know if you can turn that off.

@John Twohig 

This is still an issue in 2024, sadly. For what it's worth, here is a potential javascript-based workaround I've been looking into. I'm offering it as help to anyone else who stumbles upon this thread looking for a potential solution.

 

Background

 

The sharing URL (which contains a unique token and does not show the file name or path) does not seem to be configurable to open natively in the browser's own PDF viewer. The sharing URL looks something like this: "https://<TENANT>.sharepoint.com/:b:/s/<SITE_NAME>/<UNIQUE_TOKEN>"

 

The sharing URL redirects to a viewing URL, which has a different format. The viewing URL always opens the doc in the SharePoint viewer. The URL looks something like this: "https://<TENANT>.sharepoint.com/sites/<SITE_NAME>/Documents/Forms/AllItems.aspx?...<QUERY_PARAMS_INCLUDING_FILE_PATH>". To my knowledge, this doesn't seem to be configurable either; plus, you don't have control over it, because it's returned in the Location header for the 302 response you get from accessing the sharing URL.

 

A path-based URL (that accesses the file via the SharePoint library path) does open in the browser's own PDF viewer. The URL looks like this: "https://<TENANT>.sharepoint.com/sites/<SITE_NAME>/<PATH_TO_DOCUMENT_IN_THE_LIBRARY>/<FILE_NAME>.pdf" However, the path URL is only accessible if a) you are authenticated (logged into SharePoint), OR b) if you have previously visited the sharing URL. This is because the sharing URL sets a browser cookie that gets used for authentication later when the user tries to access the path URL.

 

Workaround / Hacky Javascript solution

 

This concept worked when tested in a new `about:blank` tab in Chrome:

 

function visit(url, shouldClose = false) {
  let w = window.open(url, "_blank");
  if (shouldClose) {
    setTimeout(() => {
      w.close();
    }, 100);
  }
}

// To get to the final "path URL" that opens natively in the browser,
// you have to do something like this:
visit(sharingURL, true);
setTimeout(() => {
  visit(pathURL);
}, 500);

 

For testing purposes, I manually put together the path URL, but if you're generating the sharing link on the backend (via Microsoft Graph API), you can likewise build the path URL from the path property of the list item fetched from the graph API.

@John Twohig I would also dearly like to be able to set PDFs in SharePoint to open in the Browser rather than the "preview" which, as you say, does not recognize all links and also does not have search capability. When using SP as a document repository, I would think a basic necessity would be for people to be able to search t hose document for information they need and use hyperlinks. While SP can be set to Open MS docs in browser, online app or desktop app by default, this does not apply to PDF which always opens in preview by default, and I believe the setting are for yourself rather than for all users.  When sharing PDFs I always either open in browser and copy that URL rather than using the copy/share function or simply delete everything in the URL after .pdf. That way, you can share the URL and it will open in browser for the recipient. Not ideal, and doesn't help with document libraries....

If I own a document library, I know all the PDFs on there are safe and,as the owner, I should be able to choose to set the default for all users to be Open in Browser. Plus, as @John mentions, open in browser or in Adobe app are still options so its not much of a security control.
@KDRUIS If you want to share a link with students that opens the PDF in a window in the browser, you can try simply removing everything in the URL after .pdf and you should find it simply opens the PDF in a browser window, not as a preview.