Open pdf in Browser not SharePoint pdf Viewer

The workaround we found for PDFs in Quicklinks WebPart to open in the browser's PDF viewer instead of SharePoint's file viewer was to add # at the end of the direct link to the PDF.

For example, the PDF link is: https://<tenant>.sharepoint.com/sites/testsite/shared%20documents/test.pdf

When adding or changing links, choose the "From a link" option and use the URL:

https://<tenant>.sharepoint.com/sites/testsite/shared%20documents/test.pdf#

The link will be rendered as:

https://<tenant>.sharepoint.com/sites/testsite/shared%20documents/test.pdf#?web=1

Microsoft may change this behaviour in the future, but so far, this is the workaround that we've been advising our content editors to use.

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....

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 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.

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 

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 🙂