PDF Viewer

When You Need a PDF Viewer in the Browser

Why have an in-browser PDF viewer at all when every OS ships one? The cases are specific but common:

1. Locked-down environments. Corporate machines that can't install Acrobat, public terminals, school computers. The browser is the only tool you have.

2. Untrusted documents. A PDF from a stranger, an attachment from a phishing-suspect email, a downloaded file you're not sure about. Opening in the browser's sandbox is safer than running through Adobe Reader or macOS Preview, both of which have had RCE vulnerabilities.

3. Embedded workflows. This tool integrates with the rest of the site's PDF utilities, view, then split, then add a watermark, then compress, all without leaving the browser.

4. No download. Sometimes you just want to peek at a PDF without it landing in your Downloads folder.

PDF.js: The Engine

This viewer is built on PDF.js, Mozilla's open-source PDF renderer (the same engine Firefox uses for its built-in viewer). PDF.js is pure JavaScript, no plugins, no native code, no installer. It parses the PDF format and rasterizes pages to HTML5 canvas elements.

What PDF.js does well:

• Text and vector rendering. Crisp at any zoom.
• Standard fonts. The 14 PDF standard fonts plus most common embedded fonts.
• Page navigation. First/last/next/prev, jump-to-page.
• Search. Full-text search across the document.
• Text selection. Click-drag to select text; copy to clipboard works.
• Zoom. Continuous zoom from ~25% to ~400%.
• Rotation. 90-degree increments.
• Encrypted PDFs. Standard encryption (RC4, AES) with password input.

What PDF.js does less well:

• Interactive forms. Display works; saving filled forms is unreliable.
• Digital signatures. Visual appearance renders; cryptographic validation is limited.
• Custom annotations. Standard annotations display; tool-specific extensions may not.
• PDF JavaScript. Embedded JavaScript actions don't run (this is also a security feature).
• 3D content. Rare 3D PDFs (CAD exports, scientific viz) don't render.

For documents that don't need these advanced features (the vast majority), PDF.js is a complete viewer.

Sandbox Security: Why In-Browser Is Safer

PDF has a long history of native-code RCE vulnerabilities:

• Adobe Reader, CVE-2010-1297, CVE-2014-0521, CVE-2018-4990, and many others. Reader runs as a privileged OS process; an exploit gets host-level code execution.
• macOS Preview, fewer CVEs but not none. CVE-2024-23286 (TIFF parsing inside PDFs) is recent.
• Foxit Reader, multiple CVEs, similar profile.

PDF.js runs in your browser's process, inside the JavaScript sandbox. Even a successful exploit gets only browser-level execution: same restrictions as any web page. No file system access, no host execution. The blast radius of "malicious PDF opens in browser viewer" is much smaller than "malicious PDF opens in Acrobat Reader."

This makes the in-browser viewer the safer choice for documents of uncertain provenance:

• Email attachments from senders you don't recognize.
• Downloads from forums or torrents.
• Files received via USB drives from outside your organization.
• Anything you'd be cautious to "double-click" but want to see the contents of.

(For truly hostile situations, viewing in a disposable VM is even safer than the browser sandbox. The browser is good enough for most threat models.)

Performance Characteristics

PDF.js renders on-demand: only visible pages are parsed and rendered. Scroll to page 50 and pages 1-49 don't render. This makes opening a 500-page PDF essentially instant.

But: parsing the document catalog and font dictionaries does happen up front. A PDF with many embedded fonts or complex object streams takes longer to "load" before the first page renders. PDFs from older or specialized tools (CAD exports, scanned PDFs with unusual structures) can be slow to parse.

Rendering speed depends on page complexity. A text-only page renders in milliseconds. A page with hundreds of vector elements (diagrams, charts) takes longer. Image-heavy pages depend on the embedded image's encoding (DCTDecode/JPEG is fast; CCITTFax is slower).

Text Selection: How It Works

PDF.js maintains a transparent HTML text layer aligned with each page's rendered canvas. The text layer contains <div> elements positioned over each text run from the page. When you select, you're selecting from the HTML layer; the underlying canvas is just visual.

This means:

• Selection works on text-bearing PDFs.
• Selection doesn't work on image-only PDFs (no text layer).
• The selection box may look slightly offset from the rendered text, alignment is approximate.
• Copy preserves Unicode characters (good) but loses formatting (no bold/italic in clipboard).

Comparing to Other In-Browser Viewers

Other viewer-as-a-service options:

• Google PDF Viewer / Google Docs. Renders server-side, returns images. Uploads your file to Google. Not private.
• Adobe Document Cloud Viewer. Uploads to Adobe. Not private.
• Smallpdf / iLovePDF Viewer. Upload-based. Not private.

The privacy difference is the whole point. If your document is OK to send to Google or Adobe, those viewers may render slightly better (especially for complex forms). If it's not, in-browser PDF.js is the only honest option.

Privacy

PDF.js runs entirely in your browser. The file is read via FileReader, parsed and rendered in JavaScript memory and to canvas elements. Page content, search queries, text you select to copy, all stay local. PDF.js fetches some font fallback data from the page bundle (the tool's own /static/ directory), not from a third-party server. Open DevTools Network during use: zero outbound requests to any tracking, analytics, or third-party server. Sensitive documents are safe.