Google’s PDF preview fails, including with PDFs made by Google Docs!

For files hosted on Google Drive, Google provides a convenient viewer sometimes referred to as “Google’s Preview” or the “Google Viewer”. 

This cloud application reads the PDF and then displays an HTML rendering directly in a browser window. This is not a fully fledged PDF viewer, as it offers only basic functionality, such as page scrolling and hyperlinks, but it’s very convenient.

The PDF Association was recently contacted by stakeholders inquiring about non-functional Table of Contents (ToC) and internal document (intra-document) hyperlinks in PDFs stored on Google Drive when viewed with Google’s Preview. This problem is a major inconvenience for all users and a significant navigational hazard for users with disabilities.

Confirming the issue

To confirm the report, I created a Google Doc test document with a Table of Contents (ToC), as automatically generated by Google Docs based on headings, an internal document hyperlink, and both active (explicitly hyperlinked) and inactive URLs. I then exported this document to both PDF and DOCX formats via Google Docs’ File → Save As feature, resulting in this PDF file. 

I then opened the exported DOCX file in Microsoft Word on Windows, and exported it to PDF again, this time using the native Microsoft PDF exporter as well as various PDF vendor plugins (including Adobe Acrobat, Adobe Acrobat as a PDF/UA-1 conforming document, and Nitro-Pro). Of course, there are many add-ins and methods to create PDFs from office applications spanning multiple platforms, so this is not a comprehensive test.

I uploaded these PDFs to Google Drive and opened them with Google’s Preview using several common browsers. I compared the navigation experiences with other PDF viewers, including:

• Browser-integrated PDF viewers (such as PDFium in Google Chrome, pdf.js in Mozilla Firefox, and Adobe technology in Microsoft Edge)
• Dedicated interactive PDF applications(such as Adobe Acrobat, Foxit’s Reader, and Apryse PDF Studio)
• Various Google mobile apps on both iOS and Android.

Unlike Google’s Preview, all browser-integrated viewers and dedicated interactive PDF applications that we tested fully supported link navigation in all the tested PDFs. However, ironically, the PDF created by Google Docs is incompatible with Google’s Preview and Google mobile apps, as the intra-document hyperlinks do not work!

Fully supporting intra-document hyperlinks

When exporting documents to PDF, users don’t specify which specific PDF feature is used “under the hood” to implement basic functionality. PDF creation software may also select different PDF features for various classes of documents, such as whether a PDF is a Tagged PDF or complies with PDF/UA-1, is optimized for the web, or contains other specific features. 

For this reason, it is vital that all PDF viewers support all aspects of common PDF features, such as intra-document links, so that all documents appear and behave as intended.  

Our research indicates that the PDF feature enabling intra-document hyperlinks (PDF Link annotations, ISO 32000-2:2020, §12.5.6.5) is only partially implemented in Google's Preview and Google mobile apps.

Technical details

PDF’s specification defines two methods by which a PDF creator can use PDF’s Link annotations to enable intra-document hyperlinks:

1. An Action using the A entry in the annotation dictionary, or
2. A PDF destination using the Dest entry in the annotation dictionary.

PDF Actions (ISO 32000-2:2020, §12.6.4) enable a variety of capabilities, but for common intra-document hyperlinks (such as ToC entries), a Go-To Action (ISO 32000-2:2020, §12.6.4.2) is typical. Like Dest, PDF’s Go-To Actions are based on PDF destinations.

PDF Destinations (ISO 32000-2:2020, §12.3.2) provide the foundation for all forms of intra-document hyperlinks via three distinct mechanisms, allowing PDF creation software a variety of options:

1. Explicit Destinations (ISO 32000-2:2020, §12.3.2.2) are PDF array objects which specify a page in the current document, a view (name), and various numeric parameters (such as (X, Y) coordinates, a zoom level, etc). For example:
   [ page /XYZ left top zoom ]
[ page /FitH top ]
2. Structure Destinations (ISO 32000-2:2020, §12.3.3) are similar to Explicit Destinations, but specify a structure element in the logical structure hierarchy rather than a page object. For example:
   [ struct-elem /XYZ left top zoom ]
[ struct-elem /FitH top ]
3. Named Destinations (ISO 32000-2:2020, §12.3.4) are either a PDF name or string object that indirectly refers to either an Explicit Destination or a Structure Destination. Named destinations may also refer to a dictionary with a D (destination) entry, and optionally, an SD (structure destination) entry. For PDF name objects, the destination is determined via a simple key lookup in the document catalog’s Dests dictionary. For PDF string objects, the destination is determined via the Dests name-tree in the document catalog’s Names dictionary.

Impact on Fragment Identifiers

In addition to supporting intra-document links, the Named Destinations feature enables the use of PDF Fragment Identifiers defined in RFC 8118, Section 3 (and in ISO 32000-2, §Annex O), allowing URLs to target specific content within a PDF document. I have previously written about PDF Fragment Identifiers and noted the inconsistent support across browsers. 

The following URL is designed to direct users to a specific location and view within the PDF at the start of the table on page 2, as shown in the Google Chrome screenshot below. Anything less, and you won’t enjoy complete support for link technology in PDF files.

https://labs.pdfa.org/FragmentTest.pdf#nameddest=Table 

Impact beyond Google Drive

In addition to its integration with Google Drive, Google’s Preview is also usable as a component for websites, as mentioned here.

NOTE: Various online forums have noted that Google doesn’t provide licensing or terms-and-conditions information for Preview, and that the use of PDF content sent to Google’s servers and presented using Google's Preview (such as for training AI) is unclear. In the absence of such information, it is recommended to avoid Google's Preview when viewing confidential documents or documents that may contain personal information.

I created a test page to test PDF viewing when using Google’s Preview as an <iframe> component.

<iframe
  id="iframe1_id"
  name="iframe1_name"
  width=400
  height=600
  src= "https://docs.google.com/viewer?url=https://pdfa.org/wp-content/uploads/2024/02/Well-Tagged-PDF-WTPDF-1.0.pdf&embedded=true"
  title="Demonstration of Google's Preview as iframe">
</iframe>

No support for RFC 8118 fragment identifiers

As far as I could determine, and as confirmed by existing issues in Google’s Issue Tracker, Google’s Preview does not support RFC 8118 (which is identical to ISO 32000-2, § Annex O), which lists the various PDF fragment identifiers that I have previously discussed. 

Our second <iframe> test simply attempts to use a fragment identifier as specified in RFC 8118 to open to a specific page in a PDF document.

Auto-hyperlinking URLs found in text

Google’s Preview automatically enables URL-like text in PDF documents, effectively adding interactive links even when the document’s author did not explicitly link the text. 

In these situations, the text’s appearance is left unchanged (i.e., there’s no visual indication of the addition of the active hyperlink), which can confuse users who expect a consistent visualization of available links (e.g., color, underline), and may not expect plain text to be clickable.

In web browsers, a floating pop-up in the lower-left corner of the screen is commonly used to show the URL, allowing users to validate links before clicking. However, in Google mobile apps, URL preview capabilities are unavailable, which poses a potential security risk to users. Unlike many desktop applications, this auto-link detection feature in Google mobile apps appears to be non-configurable, so there is no way to prevent Google’s Preview from activating all hyperlink-like text, overriding the author's intended formatting.

Conclusion

Google Drive has over 2 billion users. Google’s Preview is independently usable as a component of third-party websites. In this context, the incompatibility of Google Docs PDF export with Google’s Preview in browsers and mobile apps is a serious issue for many stakeholders.

I have reported this issue to Google, in the hope that their engineers will fully implement support for PDF’s Link annotations in the browser-based Preview and all affected Google apps. 

In the meantime, an unreliable workaround is to export Google Docs as DOCX, open the resulting file in Microsoft Word, and then export PDFs from there using a third-party export engine. It will be necessary to manually confirm the resulting functionality in Google's Preview, as this workaround will be “hit & miss” depending on specific export engines and configurations, as users simply don’t get to (and shouldn’t!) be forced to consider and choose each “under the hood” PDF feature.