Extenshiextenshi.io/blog
Back to articles
pdf extensionsextension reviewsprivacybrowser extensions

PDF extensions reviewed: Adobe Acrobat, Smallpdf, iLovePDF & Xodo compared

I compared four PDF extensions on permissions and where your documents go. Which upload your files, which stay local, and what the Adobe Acrobat flaw exposed.

Maxim Kosterin
13 min read
A hairline document sheet inside an open enso brush circle, with an orange watercolor wash bleeding out of the page and spreading past the circle's boundary.
A hairline document sheet inside an open enso brush circle, with an orange watercolor wash bleeding out of the page and spreading past the circle's boundary.

In June, a PDF extension installed on roughly 329 million browsers, by Guardio's count, turned into a way for any website to read your WhatsApp Web chats. Not a knock-off from an anonymous developer. Adobe's own Acrobat extension, shipped by one of the largest software companies on the planet, broken by a routine update. The public write-up landed in July; the vulnerable build had been sitting in browsers a month earlier.

That's the reason I finally sat down with the PDF category. It's one of those boring, universal utilities — everyone installs one, nobody thinks about it again — and the permissions involved are anything but boring. So I lined up four of the big ones: Adobe Acrobat, Smallpdf, iLovePDF and Xodo, on the two questions that decide everything: how much of the web can this thing read, and where does my document physically end up?

Quick verdict

  • Xodo (Apryse) — the only one of the four whose vendor says most tools process your file on your device, locally, per Xodo's own product pages; the tools that do need an upload delete the file after an hour. If your PDFs are contracts, medical scans or anything you'd redact before emailing, this is the design you want — with the caveat that "most" isn't "all", so check the specific tool.
  • Smallpdf — a genuine cloud service. Your file gets uploaded. Smallpdf is ISO 27001 certified and states 256-bit TLS in transit and permanent removal from its servers one hour after processing. Fine for a receipt, wrong shape for a legal document.
  • iLovePDF — same cloud model, EU-based. Its security page states files are permanently deleted within two hours, TLS in transit, ISO/IEC 27001, GDPR. One caveat worth knowing: signed documents are the exception, retained for up to five years to meet legal requirements.
  • Adobe Acrobat — by far the widest permission footprint of the four, and the only one with a fresh CVE against it. Adobe patched fast and well. I still wouldn't leave it installed unless you actually use Acrobat desktop.

The interesting part: the permission list and the data destination are separate questions, and the extension with the most permissions is not the one that ships your file furthest away. Let me unpack both.

What these extensions actually do

All four sell the same convenience: you're staring at a PDF in a browser tab, or you want to turn a page into one, and you'd rather not download the file, open a desktop app, and re-upload it somewhere.

Under that convenience are two completely different architectures.

Cloud toolkits — Smallpdf and iLovePDF — are websites with an extension bolted to the front. The extension is mostly a launcher: it grabs the file or URL, hands it to the service, and the actual compressing/merging/converting happens on the vendor's servers in Switzerland or Spain. Your document leaves your machine. That's not a scandal, it's the design, and both vendors document it plainly.

Browser-side toolkits — Xodo is the example here — do most of the work in JavaScript inside the tab. Apryse, which owns Xodo, has been building PDF engines for two decades, and that engine runs client-side. For those tools the document never makes the trip; Xodo is explicit that a minority of its tools still require an upload, and says those files are deleted after an hour.

Adobe Acrobat is a third thing entirely: a bridge to the Acrobat desktop application. That's why it wants a permission the others don't need, and it's the single most important line in its manifest.

Security analysis: the permissions each one holds

Here's Adobe's own list of what the Acrobat extension requests, straight from Adobe's documentation: tabs, downloads, context menus, native messaging, history, and host permissions covering all URLs on the http, https and file schemes.

Read that again, because four of those are individually significant:

  • Host permissions on all URLs is the big one — the "read and change all your data on all websites" warning. I've written about what that permission really buys an extension; short version, it's a standing window into every page you have open, not just PDFs.
  • nativeMessaging lets the extension talk to a program installed on your operating system. That is the one permission that reaches outside the browser sandbox entirely — I broke down why native messaging is the permission I read most carefully.
  • history — Adobe's docs say it's used to fetch recent URLs. It's also, mechanically, access to where you've been. In the current build it's an optional permission, which is the right call — you get asked rather than assumed.
  • file scheme access means it can operate on local files opened in the browser.

None of that is unreasonable for what Acrobat does. Rendering PDFs in a custom viewer, converting a web page to PDF, and handing a document to the desktop app genuinely require most of it. That's the trap with utility extensions: the permissions are justifiable one at a time and enormous in aggregate.

There's a second problem, and it's the one I'd actually flag. That documentation page was last updated in May 2023. I pulled the manifest out of the build that's shipping as I write this — version 26.8.1.4 — and the required permission list is more than twice as long: contextMenus, tabs, downloads, nativeMessaging, webRequest, webNavigation, storage, scripting, alarms, offscreen, cookies, sidePanel, declarativeNetRequest, fileSystem and identity, on top of <all_urls> host access and content scripts injected into every http, https and file page. history and bookmarks have since moved to optional permissions, so Adobe's doc is over-stating one thing and under-stating a dozen others. cookies and scripting in particular are not small: one can read the session cookies your browser holds for a site, the other injects code into pages.

I'm not accusing Adobe of hiding anything — this is what documentation rot looks like at a company shipping fast. But it means the vendor's own permissions page is not a reliable picture of what you're installing. The manifest is.

Then there's the Product Improvement Program. Adobe states that participation is voluntary, that no personal information is collected, and that URL information is not sent back to Adobe. What it does send: browser type and version, Adobe product version, which menu options and buttons you click, and domain information — all tied to an identifier associated with your browser. Domain-level telemetry keyed to a persistent identifier is not nothing, even if no single field is your name. The opt-out is a checkbox: right-click the Acrobat icon, Options, clear "To improve product features…", Save.

The other three are in a different league, and I checked their manifests the same way. Here's what each one actually asks for, pulled from the builds live in the store on 6 August 2026:

Extension Version API permissions Host reach
Adobe Acrobat 26.8.1.4 15, incl. nativeMessaging, cookies, webRequest, scripting, identity (+ optional history, bookmarks) <all_urls>, content scripts on every http / https / file page
iLovePDF 6.11 6: tabs, activeTab, downloads, storage, unlimitedStorage, scripting every https origin, but content scripts only on ilovepdf.com and Gmail
Smallpdf 0.23.21 3: storage, notifications, alarms no host permissions declared — but a content script on every http / https / ftp / file page
Xodo 1.8 none none, no content scripts at all

Two things jump out. Xodo's extension requests nothing — it's a shortcut to their web app, which is why it can't do much harm on its own and also why the privacy question moves to xodo.com rather than the extension. And Smallpdf's tiny permission list is a little misleading: three API permissions look modest, but a content script matching every page still means it can read what's on your screen. The permission count is not the metric. Reach is.

If you're unsure what a given permission string means before you accept it, Chrome's permissions reference is the authoritative decoder.

One practical note on this category: "PDF" is a crowded search term, and several similarly-named listings exist for the same brand. Check the publisher field, not the name. ILOVEPDF S.L. — registered in Barcelona, per its own privacy policy — is the publisher behind the official iLovePDF listings.

The Adobe flaw, and why it matters more than the permission list

Researchers at Guardio Labs found a vulnerability chain in the Acrobat Chrome extension, tracked as CVE-2026-48294 and named HermeticReader. BleepingComputer reported that an attacker-controlled page could disguise its own commands as internal extension messages, activate the extension's WhatsApp integration, and redirect its privileged DOM operations into a WhatsApp Web tab — pulling out chats, contacts and message previews in plain text. All it took was getting a victim with the extension installed to visit a page.

Adobe issued the CVE itself and scored it 7.4, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N), describing it as a UXSS-class cross-origin data disclosure affecting extension versions 26.5.2.2 and earlier. Malwarebytes reports the fix landed in 26.5.2.3, delivered automatically.

The timeline is the part worth sitting with. Guardio's write-up says Adobe shipped v26.5.2.1 on 3 June, and their tooling had the exploit chain confirmed in under four hours. They reported it; Adobe acknowledged, triaged, fixed and shipped over a single weekend. CISA's own enrichment of the CVE records exploitation as none. Adobe credited the researchers publicly. As vendor responses go, that's close to the best case — and I want to be clear that Adobe comes out of this looking good.

So why does it still bother me? Because nothing on the store page changed. Same name, same publisher badge, same install count, same 4.4-star rating, before and after the vulnerable build shipped. If you reason about extension risk as a one-time decision you make at install, this entire class of exposure is invisible to you. The risk lives in the update, and updates land silently.

That's the same structural problem behind extensions that turn hostile after an ownership transfer — the difference here is that nobody acted in bad faith at all. A first-party vendor with a real security team shipped a bug. Version-level visibility is the only thing that catches either.

How the risk math actually shakes out

I won't hand you a single number, because a score that averages "where my file goes" with "how many pages this can read" hides the thing you care about. Two axes, judged separately:

Blast radius if the extension is compromised — driven purely by permissions. Adobe Acrobat is the widest by a distance: all-URLs host access plus native messaging means a bug becomes a cross-origin read primitive and a path toward the OS. HermeticReader is exactly that scenario, realised. The other three are meaningfully narrower.

Document exposure in normal operation — driven by architecture, and it inverts the ranking. Xodo's in-browser processing means that for most of its tools, routine use sends the file nowhere. Smallpdf and iLovePDF both upload by design; the question isn't whether your file leaves, it's who holds it and for how long — one hour for Smallpdf, two for iLovePDF, both with ISO/IEC 27001 certification and documented deletion policies.

The two axes disagree, which is why "is this extension safe" is the wrong question. Ask instead: safe against what? If you want to see both dimensions for a specific listing, the PDF category in the Extenshi catalog lays out declared permissions and version history side by side.

Alternatives worth knowing

  • Chrome's built-in PDF viewer. Costs zero permissions. It reads, prints, fills basic forms and does nothing else. For a large share of people, the extension solves a problem they don't have.
  • Xodo if you need editing and want the file to stay on your machine.
  • Smallpdf or iLovePDF for one-off conversion and compression of documents that aren't sensitive — both are transparent about being cloud services, which is more than most of this category manages.
  • Adobe Acrobat — reasonable if you own and use Acrobat desktop, since nativeMessaging is doing real work for you. If you don't, you're carrying the widest permission set in the category for a viewer you could replace with the one Chrome already ships.

Final recommendation

My honest take: uninstall the PDF extension you don't remember installing. This category is heavily preinstalled — Acrobat Reader has historically pushed its Chrome extension during desktop installs — and a lot of people are carrying all-URLs access for a feature they used once in 2023. That's the same neglected-utility pattern I found across the screenshot extension category.

If you keep one, match it to the job. Sensitive documents → local processing, Xodo or the desktop app. Throwaway conversions → a cloud toolkit with a published deletion policy. Heavy Acrobat user → keep Adobe's, turn off the Product Improvement Program, and stay current on updates, since 26.5.2.3 is the version you want.

And whatever you pick, check it after updates, not just before installs. HermeticReader shipped inside an extension that looked identical, on the store page, the entire time it was exploitable.

See the security report for your PDF extensions →

Sources

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If any entity referenced in this article believes information is inaccurate, contact [email protected] and we will review and update.

Related Articles