IE for Chrome

Bridging Chrome and Internet Explorer with Native Messaging

25 September 2026 by

Client: Internal tooling

Role: Developer

Period: Apr 2026

Status: Prototype

Tech stack: Chrome Extension (Manifest V3), Native Messaging, C#, .NET Framework 4.8, WinForms, WebBrowser (Trident) control, Windows Registry, PowerShell, Chrome Enterprise Policy

Some legacy business web apps still only work in Internet Explorer. This is a home-built alternative to commercial 'IE Tab' products: a Chrome extension that hands matching URLs to a small C# helper, which renders them with the Windows IE engine in the right document mode. It registers per-user without admin rights and can be managed by IT through Chrome policy.

The problem

Internet Explorer is retired, but plenty of business software isn't. Old line-of-business apps that rely on ActiveX, legacy document modes or IE-only behaviour still exist. Asking staff to keep a separate browser around (and remember when to use it) causes constant friction. Commercial "IE Tab" products solve this, but they're licensed per seat.

How it works

Chrome
 ├─ right-click (page / link / frame) · popup button · auto-match URL patterns
 └─ background service worker ──► Native Messaging (stdin/stdout)
                                        │  { cmd: "open", url, ieDocumentMode }
                                        ▼
                          ietabhelper.exe  (C#, .NET Framework 4.8)
                          ├─ launched by Chrome? → read message, relaunch self, reply, exit
                          ├─ relaunched copy → WinForms window with WebBrowser (IE engine)
                          └─ double-clicked? → registration UI

Engineering highlights

Speaking Chrome's wire protocol

Native Messaging frames every message as a 4-byte length prefix followed by UTF-8 JSON over stdin/stdout. The helper reads exactly that many bytes, enforces a 1 MB cap in both directions, and replies in the same format.

One executable, three roles

The helper works out how it was started. Using the Win32 GetFileType call, it checks whether stdin is a pipe:

Pipe → Chrome started it as a messaging host. Chrome expects one request, one response and a quick exit, so the helper relaunches itself in a separate process with the request encoded in Base64, replies { "success": true } and exits immediately.
No pipe → a person double-clicked it, so it shows a registration window.
Relaunched with a payload → it opens a browser window with the embedded IE engine and navigates.

The right IE document mode

Legacy apps often need a specific mode (IE7–IE11). Before navigating, the helper sets the per-user FEATURE_BROWSER_EMULATION registry value for its own process, so the embedded engine renders in the requested mode.

Installation without admin rights

Registration validates the 32-character extension ID, writes the host manifest to the user's local app data and sets the Chrome native-messaging registry key under HKCU. No administrator prompt is needed. A PowerShell script does the same for scripted rollouts, and the extension's options page shows its ID with a copy button to make setup easy.

Built for IT management

The extension ships a managed-storage policy schema. IT can push URL patterns, the default IE mode and close-tab behaviour through Chrome enterprise policy, and those values override user settings. A three-second de-duplication window stops the same URL opening twice when several triggers fire together.

By the numbers

~450 lines of C#, ~300 lines of extension JavaScript, ~35 lines of PowerShell

Takeaway

Native Messaging is a little-known corner of the Chrome platform, but it's the right tool whenever a browser extension needs something only the operating system can do. The interesting engineering was all in the edges: the framing protocol, process lifecycle and registration.

in Projects