desktest.net
guide

PDF Test Guide

The PDF Test answers three questions about a workstation: can this browser render PDFs inline, does a sample PDF actually render, and do forms and print work? This guide explains what each stage does, how to read the verdict, and what the common failure modes mean.

Open the PDF Test ->

What does the PDF Test check?

The test runs three probes in order. A failure in an earlier stage stops the later ones because the later checks would not be meaningful.

Stage 1, capability probe. Reads navigator.pdfViewerEnabled, enumerates navigator.plugins and navigator.mimeTypes, and fingerprints the user agent. Answers: can this browser render PDFs inline? Result is one of: yes (modern browser, API present, flag true), yes-but-legacy (older browser registering an application/pdf MIME handler the old way), no (download-only), or unknown (very old browser).

Stage 2, render probe. Loads the same-origin sample PDF (/pdf-test/sample.pdf) into a single iframe by setting its src. Waits for the load event or a five-second timeout, then asks the user to confirm what they see. Answers: does a sample PDF actually render? User confirmation is required because iframes never fire error on bad content, and Chrome can silently swap the render for a download with no scriptable signal.

Stage 3, interactive probe. Asks the user to type into a known AcroForm field, then tries to print the PDF itself with iframe.contentWindow.print() after a user click. Where the built-in viewer blocks that (Chrome, Edge, and Firefox do, by design), the step guides the user to print the PDF with the viewer's own control (its toolbar print button, or Ctrl+P with the PDF focused). Answers: do forms and print work? Both halves of stage 3 need a human Yes/No because the privileged PDF viewer DOM is opaque to outside JavaScript.

When should I run this?

Reading the results

Each of the three rows shows a status badge: Pending, Running, Pass, Fail, or Partial. A Fail row expands automatically with a fix block. Partial means one half of a stage worked and the other did not (only happens in stage 3, where form input and print are checked separately).

Above the rows, the verdict panel summarizes the run with a likely cause and a recommended next step. The verdict treats Partial stage 3 as acceptable because most workflows survive one of those two features being broken.

On failure, the Copy Diagnostic Report button puts a plain text report on the clipboard: timestamps, user agent, platform, every stage's status, the raw navigator.pdfViewerEnabled value, iframe load signal and elapsed milliseconds, the user's Yes/No answers, the scripted print result, and any CSP violations captured. Paste it into the ticket.

PDF handler differences

Every modern browser ships its own PDF viewer. A PDF that renders correctly in one may break in another.

Adobe Acrobat NPAPI plugin. The historic option. Chrome dropped NPAPI in September 2015 (Chrome 45); Firefox dropped it in March 2017 (Firefox 52 ESR was the last). The Acrobat browser plugin cannot be put back. Acrobat still opens PDFs as a standalone app and ships an acrobat:// protocol handler, but inline browser rendering through Acrobat is gone.

Chrome and Edge. Built-in viewer backed by PDFium, the same C++ engine that ships in Chromium. Renders standard PDFs well, supports AcroForm fields, displays digital signatures. Does not render XFA. Annotation tooling is limited compared to Acrobat.

Firefox. PDF.js, a pure-JavaScript renderer Mozilla maintains. Renders most PDFs fine, supports AcroForm filling, added partial XFA support in Firefox 93. Slower than PDFium on very large PDFs.

Safari. PDFKit, backed by the same Quartz PDF stack as the rest of macOS. Renders well, supports AcroForm fields, does not render XFA. Safari on iOS often downloads PDFs from iframes regardless of the inline capability flag.

Common failures and fixes

Stage 1 has four possible verdicts; the test's app.js uses them as the routing key for everything that follows.

inline-capable

The good outcome from stage 1. navigator.pdfViewerEnabled returned true; the test proceeds to stage 2. If stage 2 fails after this, the cause is between the browser flag and the actual render pipeline: CSP, sandbox, extension, antivirus, or a per-browser download override.

inline-capable-legacy

Older browser that predates the pdfViewerEnabled API (added across all engines by early 2023) but registers an application/pdf MIME handler or plugin entry the old way. Treated as pass. Most builds in this bucket still render PDFs fine; the browser itself is overdue for an update.

download-only

The browser reports it cannot render PDFs inline. Almost always a setting, not a missing feature.

unknown

None of the signals returned a value: navigator.pdfViewerEnabled was absent and no plugin or application/pdf MIME handler was registered. The test does not treat this as a failure, because some browsers render PDFs inline without exposing any of those signals. It proceeds to the render test, which is authoritative: if the sample renders, the capability step is marked pass on that proof. If the sample does not render, update the browser. The pdfViewerEnabled API is Baseline since March 2023 (Chrome 94+, Edge 94+, Firefox 90+, Safari 17+).

CSP violations during render

Stage 2 returns blank and the report shows a captured violation against object-src or frame-src: the embedding page has a Content Security Policy that blocks PDF embeds. Add 'self' (or the PDF's origin) to both directives. The PDF Test page sets a permissive CSP for these so it does not block its own sample.

Print does not open a dialog

Form input worked but print did not. Chrome, Edge, and Firefox block scripted print of the embedded PDF by design, so the test asks you to print with the viewer's own control (its toolbar print button, or Ctrl+P with the PDF focused). If that produces no dialog, open the PDF in its own tab and print from there. In an app that embeds a PDF in a sandboxed iframe, a missing allow-modals token also suppresses print; add it to the embedding iframe.

Print pipeline blocked

If the scripted print throws and printing from the viewer's own control also does nothing, the workstation's print pipeline is broken outside the browser. Confirm with the Printer Test before chasing the PDF viewer.

For IT admins

Most workplaces are fine letting Chromium PDFium or Firefox PDF.js handle PDFs. Forcing Adobe Acrobat as the default handler is usually wrong: it adds licensing and update cost for no benefit. It is the right move when a workflow needs Acrobat's strengths: complex digital signing, XFA dynamic forms, stamping, or redaction.

Set Acrobat as the default .pdf handler on Windows by hand: Settings > Apps > Default apps > Choose default apps by file type > .pdf > Adobe Acrobat Reader.

For Group Policy or fleet rollouts, the file association lives at HKLM\Software\Classes\.pdf and per-user at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice. Export defaults with Dism /Online /Export-DefaultAppAssociations and deploy through the "Set a default associations configuration file" policy. Editing UserChoice directly is not supported; Windows resets it.

The default file handler controls what happens when a downloaded PDF is double-clicked, not the browser's inline behavior. The PDF Test passes when the browser renders inline regardless of the OS default.

Behind the scenes