Microsoft has set a firm deadline: the legacy PDF engine built into Edge and WebView2 will be permanently removed in September 2026. The company is pushing all PDF rendering to a new, more capable engine powered by Adobe Acrobat, and for enterprise IT teams, the clock is already ticking. Applications that rely on the old WebView2 reader to display invoices, reports, contracts, or other documents must be tested and migrated well before the cutoff — or risk sudden breakage.

The change touches two distinct but related surfaces: the Microsoft Edge browser itself, and the WebView2 runtime that powers embedded browser experiences inside countless Windows applications. While the browser transition to the Adobe-backed reader is already well underway — with a phased rollout starting in Edge version 141 this October — the real challenge lies in the scattered landscape of line-of-business apps that quietly use WebView2 to show PDFs.

The Switch to Adobe Acrobat in WebView2

Microsoft now ships two separate policies to control PDF behavior:

  • NewPDFReaderEnabled governs Microsoft Edge. It flips the browser to the Adobe-powered reader.
  • NewPDFReaderWebView2List controls which WebView2-hosted applications adopt the new engine.

These policies are independent: turning on the new reader in Edge does nothing for apps that embed WebView2. That split is deliberate. An organization might fully trust the browser to handle PDFs with Adobe’s renderer, but a line-of-business application that generates or displays critical documents requires its own validation cycle.

The WebView2 policy, available since runtime version 116, lets administrators specify applications by executable name (e.g., ContosoInvoices.exe) or Application User Model ID (AUMID). A wildcard * can enable the new reader for every WebView2 app on a device, but that approach is risky without thorough testing. Each entry requires a restart of the target application before the change takes effect.

On the browser side, Microsoft will begin the enterprise rollout of the Adobe-powered reader in Edge Stable version 141, starting in October 2025 and completing by March 2026. By then, the legacy engine will still be available, but only as a transitional fallback. Come September 2026, that fallback vanishes.

Who’s Affected and What Changes

Home users and power users will likely notice little disruption. If you’re reading PDFs directly in Edge, the switch to the Adobe engine has been underway for months and generally delivers better rendering, smoother scrolling, and stronger security. Some niche workflows — like filling complex forms or using digital signatures — may behave differently, but overall the experience is a step up.

The impact is far more consequential for IT administrators and developers. Any custom or third-party application that displays PDFs inside its own window may rely on WebView2’s legacy reader. These apps often handle business-critical documents: a hospital’s patient records viewer, a bank’s statement generator, a logistics firm’s shipping manifest tool. Testing must happen app by app, because the policy can be scoped to individual executables or AUMIDs.

Microsoft’s documentation explicitly warns that enabling the policy for one application may also affect other applications that share the same WebView2 user data folder — a subtle interaction that demands extra attention when multiple apps from the same vendor coexist.

Why Now? A Timeline of PDF Migrations

Microsoft first announced its partnership with Adobe to revamp the PDF experience in Edge in early 2023. Since then, the Adobe-powered reader has rolled out gradually to consumers and unmanaged devices. The enterprise side, however, has remained on the legacy engine by default, giving organizations time to plan.

Now the deadlines are coming into sharp focus:

  • October 2025: Edge Stable version 141 begins phased enterprise rollout of the new PDF reader.
  • March 2026: The rollout completes; all Edge browsers under management can use the Adobe engine.
  • September 2026: The legacy PDF engine is removed from both Edge and WebView2. Any application still configured to use it will simply break.

This timeline means IT teams cannot afford to wait. While the legacy engine remains available until September 2026, it is only a compatibility crutch. After that date, the NewPDFReaderWebView2List policy must be actively configured — either by explicitly listing approved applications or by setting the * wildcard — to avoid rendering failures.

Getting Your Apps Ready: A Practical Roadmap

Microsoft’s policy documentation lays out the technical levers, but it doesn’t prescribe a migration methodology. Based on community experience from WindowsForum and Microsoft’s own advisory channels, a phased approach works best:

1. Build an inventory. Identify every application that might use WebView2 for PDFs. Ask application owners direct questions: Does the app display PDFs inside its own window? Does it use WebView2 for that? Which documents are business-critical? An app with no identified owner should be an explicit exception, not an early tester.

2. Start with a pilot. Choose one or two low-risk applications with active business and technical owners. Document the exact executable name or AUMID, then add only that identifier to NewPDFReaderWebView2List with a value of true. Restart the application and validate the entire PDF workflow: opening, searching, printing, saving, form interactions, and document handoffs.

3. Expand in waves. After a successful pilot, add more applications in manageable groups, monitoring help-desk tickets and user feedback after each wave. Use the * wildcard only after completing enough discovery and validation to accept the wider impact.

4. Treat the legacy reader as a time-limited exception. If an application fails testing, remove its entry from the policy list to fall back to the current reader while you investigate. But every such exception must carry an expiry date before September 2026 and a plan to resolve the incompatibility.

5. Deploy separately for Edge and WebView2. Configure NewPDFReaderEnabled for the browser according to your usual Edge update cadence. Do not assume that browser acceptance testing proves WebView2 app readiness. The policy for WebView2 must be managed independently through Group Policy or Intune.

For Intune, the setting lives under Microsoft Edge WebView2 in the Settings Catalog. For Group Policy, it’s in Computer Configuration > Administrative Templates > Microsoft Edge WebView2. In both cases, enter one identifier per list entry; do not combine multiple apps into a single comma-separated value.

What Comes Next

Microsoft’s removal of the legacy PDF engine is part of a broader shift toward modern, Chromium-based rendering across Windows. The company has been steadily tightening integration with Adobe, and the September 2026 cutoff is likely firm. However, as with any large-scale deprecation, the schedule could slip if significant compatibility issues emerge during the enterprise rollout. IT teams should watch the Microsoft 365 admin center and the Edge release notes for any adjustments.

A more immediate concern is security: once the legacy engine is no longer serviced, any application that still tries to use it will not only break but could also expose users to unpatched vulnerabilities. The safest course is to complete migration well before the deadline, leaving time for thorough testing and vendor coordination.

The message from Redmond is clear: the days of the old PDF reader are numbered. For most Windows users, that’s a quiet improvement. For the people who keep business applications running, it’s a project that deserves a place on the roadmap today.