AdapterJS is a JavaScript shim developed by Temasys Communications that normalizes WebRTC API differences across browsers, handling vendor prefixes, missing methods, and plugin-based fallback for legacy browsers like Internet Explorer. It wraps native WebRTC interfaces so developers can write a single codebase that works across Chrome, Firefox, Safari, Edge, and older browsers. For modern projects that want cross-browser WebRTC without managing shims manually, VideoSDK's JavaScript SDK handles browser compatibility internally at the SDK level.
Cross-browser WebRTC remains one of the most frustrating challenges for developers building real-time communication apps in 2026. Despite the W3C WebRTC specification being stable for years, browsers still implement it differently, with varying prefix conventions, partial API coverage, and legacy gaps that break production code.
AdapterJS, developed by Temasys Communications, was built to solve exactly this problem. It acts as a compatibility layer that intercepts WebRTC API calls and normalizes them so your application behaves consistently regardless of the browser or device it runs on.
In this guide, you will learn what AdapterJS does, how it works under the hood, how to set it up in a project, when to choose it over alternatives like webrtc-adapter, and how modern solutions like VideoSDK can eliminate browser compatibility headaches entirely.
What is AdapterJS?
AdapterJS is a JavaScript library that provides a unified WebRTC API surface across browsers by polyfilling missing interfaces and normalizing vendor-specific implementations. Temasys Communications originally created it to address the fragmented WebRTC landscape where Chrome, Firefox, Safari, and Internet Explorer each exposed different API names, prefixes, and behaviors.
The library works by detecting which browser the user is running and injecting the appropriate polyfills before your application code executes. For browsers with native WebRTC support, AdapterJS normalizes method names and event handling so you write one set of calls. For browsers without native support, specifically Internet Explorer and older versions of Safari, AdapterJS routes WebRTC calls through the Temasys WebRTC plugin, a browser extension that provides a native-quality WebRTC implementation.
Core features include polyfills for RTCPeerConnection, getUserMedia, RTCIceCandidate, media stream handling, and screen sharing via extension-based APIs. The library also fires a custom event called webRTCReady that signals when the shim has finished initializing and your application can safely begin using WebRTC APIs. VideoSDK's JavaScript SDK handles this same normalization internally, wrapping browser-specific WebRTC implementations behind a consistent room-based API so developers never manage prefixes or plugin fallbacks directly.
AdapterJS differs from the newer webrtc-adapter library in one critical way: it includes a plugin fallback mechanism for browsers that lack native WebRTC entirely. The webrtc-adapter library, maintained by the WebRTC project team, focuses only on normalizing APIs across browsers that already have native WebRTC support and does not provide any plugin-based fallback.
Here is a high-level view of how AdapterJS sits between your application and the browser's native WebRTC stack:
Browser Compatibility Landscape
The WebRTC browser landscape in 2026 is far more unified than it was five years ago, but significant edge cases remain that justify using a shim like AdapterJS. Chrome, Firefox, and Edge (Chromium-based) all ship complete native WebRTC implementations with near-full spec compliance. Safari has improved dramatically since version 11 but still has quirks around screen sharing, simulcast, and certain media constraints. Internet Explorer, while officially end-of-life, still appears in enterprise environments where legacy browser support is a hard requirement.
Specific browser quirks that AdapterJS addresses include vendor prefixes on older browser versions such as webkitRTCPeerConnection and mozRTCPeerConnection, differences in how getUserMedia constraints are interpreted, missing or non-standard screen share APIs that require browser-specific extensions, and inconsistent handling of ICE candidate events across Safari and Chrome.
The table below summarizes the browser support landscape that AdapterJS targets:
| Browser | Native WebRTC | Minimum Version | Screen Share | Plugin Needed |
|---|---|---|---|---|
| Chrome | Yes | 23+ | Yes via extension | No |
| Firefox | Yes | 22+ | Yes built-in | No |
| Edge Chromium | Yes | 79+ | Yes | No |
| Safari | Partial | 11+ | Limited | Sometimes on older |
| Internet Explorer | No | N/A | No | Yes |
| Opera | Yes | 18+ | Yes via extension | No |
| iOS Safari | Partial | 11+ | No | Sometimes on older |
The most problematic column here is the plugin requirement. For any application that must support Internet Explorer or Safari versions below 11, AdapterJS with the Temasys plugin is one of the few solutions that provides a working WebRTC experience without requiring users to switch browsers.
If your application targets only modern Chromium-based browsers and recent Safari versions, you may not need AdapterJS at all. A solution like VideoSDK's React SDK abstracts browser differences at the SDK level, so you never touch raw WebRTC APIs directly.
How AdapterJS Works Under the Hood
AdapterJS operates through a combination of feature detection, API wrapping, and conditional plugin loading that executes before your application code runs. Understanding this flow helps you debug issues and decide whether AdapterJS is the right tool for your project.
When the AdapterJS script loads, it immediately begins detecting the browser type and version. It checks for the presence of native WebRTC interfaces like RTCPeerConnection and getUserMedia, examining both unprefixed and prefixed variants. Based on what it finds, AdapterJS builds a normalized API surface that your application interacts with.
For browsers with native WebRTC support, the shim wraps the existing APIs to normalize method signatures, event names, and constraint formats. Your application calls a single consistent API, and AdapterJS translates those calls into whatever the browser expects internally.
For browsers without native WebRTC, AdapterJS checks whether the Temasys WebRTC plugin is installed. If the plugin is present, AdapterJS routes all WebRTC calls through it. If the plugin is not installed, AdapterJS can be configured to prompt the user to install it, or it can fire a callback that lets your application handle the situation gracefully.
The webRTCReady event is central to how AdapterJS manages initialization timing. Because plugin detection and loading happen asynchronously, your application cannot assume WebRTC APIs are available the moment the page loads. The webRTCReady event fires once AdapterJS has completed all detection, wrapping, and plugin initialization, signaling that your application can safely begin creating peer connections and accessing media devices.
Here is the initialization and fallback flow:
This architecture means AdapterJS adds a small initialization delay to your page load, typically negligible on modern browsers but potentially noticeable when the plugin path is triggered on legacy browsers. In production, you should account for this delay in your user experience design, perhaps showing a loading indicator until webRTCReady fires.
Setting Up AdapterJS in a Project
Setting up AdapterJS involves choosing a distribution method, including the script in your project, and waiting for the readiness event before using any WebRTC APIs. The process is straightforward but has several decision points that affect your production deployment.
Choosing a Distribution Method
AdapterJS is available through three primary channels: a content delivery network hosted by Temasys, installation via npm for projects using a bundler like Webpack or Rollup, and a local build downloaded from the official Temasys AdapterJS GitHub repository. The CDN approach is fastest for prototyping and simple projects. The npm approach is better for production applications that use a module bundler and want version control over their dependencies. A local build gives you maximum control but requires manual updates when new versions are released.
Including the Script and Verifying Readiness
After selecting your distribution method, include the AdapterJS script in your HTML page, ideally in the head section or before your application script. The library initializes automatically on load. Your application should listen for the webRTCReady event before attempting to access any WebRTC APIs. This event guarantees that all polyfills are in place and any plugin detection has completed.
The logical flow is: load the AdapterJS script, register a listener for the webRTCReady event, and inside that listener begin your WebRTC initialization logic such as requesting media devices or creating peer connections. If you call WebRTC APIs before webRTCReady fires, you risk hitting undefined interfaces or inconsistent behavior on browsers that require the plugin path.
Common Pitfalls
Several issues commonly trip up developers when integrating AdapterJS. Version mismatches between the AdapterJS script and the Temasys plugin can cause silent failures where the plugin loads but WebRTC calls do not route correctly. Always use compatible versions of both components.
The plugin flag usage matters: AdapterJS can be configured to enable or disable the plugin fallback path. If you set the flag incorrectly, users on Internet Explorer or older Safari will see broken video instead of a plugin install prompt.
HTTPS is a hard requirement for WebRTC in all modern browsers, and AdapterJS does not change this. getUserMedia calls on HTTP pages will fail silently or throw permission errors. Always serve your application over HTTPS in both development and production. If you need a quick local HTTPS setup for testing, use a tool like mkcert or serve your dev environment through a tunneling service that provides HTTPS endpoints.
For a more comprehensive approach that eliminates these setup concerns entirely, VideoSDK's JavaScript SDK and React SDK handle all browser compatibility, HTTPS requirements, and fallback logic internally, so you can focus on building features rather than debugging browser quirks.
Real-World Use Cases
AdapterJS shines in scenarios where browser diversity is high and dropping support for any browser means losing users or revenue. Several categories of applications benefit significantly from its compatibility layer.
Telehealth Platforms
Telehealth applications serve patients across a wide demographic range, many of whom use older devices and browsers. A hospital system running Windows 7 with Internet Explorer cannot simply be told to switch to Chrome. AdapterJS with the Temasys plugin allows these patients to join video consultations without changing their setup, which is critical for accessibility and compliance with healthcare regulations that mandate equal access.
Enterprise Video Conferencing
Enterprise environments often have locked-down IT policies that restrict browser installation. If a company standardizes on Internet Explorer 11 or an older version of Safari, the IT team will not approve a WebRTC application that does not work on those browsers. AdapterJS provides the compatibility layer that makes enterprise deployment possible without fighting IT policies.
Educational Web Apps
Online education platforms frequently use screen sharing for tutoring sessions and collaborative whiteboarding. Screen share APIs vary significantly across browsers, with Chrome requiring a browser extension, Firefox supporting it natively, and Safari offering limited or no support depending on the version. AdapterJS normalizes these differences so the education platform can offer screen sharing without browser-specific code paths.
Case Study: SaaS Support Ticket Reduction
A SaaS company providing remote customer support video found that approximately 30 percent of their support tickets were related to browser compatibility issues, primarily from users on Safari and Internet Explorer. After integrating AdapterJS with the Temasys plugin fallback, they reported a 30 percent reduction in browser-related support tickets within the first quarter. The plugin fallback caught users who previously saw blank screens or error messages, and the normalized API surface eliminated edge cases in their peer connection logic.
For new projects in 2026, consider whether you need to solve browser compatibility at the WebRTC API level or whether a higher-level solution like VideoSDK's code samples can provide the same cross-browser support with less maintenance overhead.
Alternatives to AdapterJS
The most prominent alternative to AdapterJS is the webrtc-adapter library, maintained by the WebRTC project team and hosted on the official WebRTC adapter GitHub repository. This library takes a different approach: it focuses exclusively on normalizing APIs across browsers that already have native WebRTC support, without providing any plugin-based fallback.
webrtc-adapter Overview
The webrtc-adapter library is actively maintained and tracks the latest WebRTC specification changes closely. It handles prefix normalization, constraint format differences, and new API migrations as browsers update their implementations. Many production WebRTC applications and even some SDK vendors use webrtc-adapter internally as their compatibility layer.
Key Differences
The primary difference is plugin support. AdapterJS includes the Temasys plugin fallback for Internet Explorer and older Safari, while webrtc-adapter does not. If your application must support browsers without native WebRTC, AdapterJS is the only option between the two. If you only target modern browsers and want the most actively maintained shim, webrtc-adapter is the better choice.
Maintenance activity also differs. The webrtc-adapter library receives regular updates aligned with browser releases and spec changes. AdapterJS updates less frequently, reflecting its more stable but narrower focus on legacy browser support.
When to Skip the Shim Entirely
For most new projects in 2026, the better question is whether you need a WebRTC shim at all. Using a managed SDK like VideoSDK eliminates the need for any shim because the SDK handles browser differences, connection management, and media routing as part of its core functionality. This approach reduces your dependency surface and shifts the burden of tracking browser updates to the SDK provider.
Decision Guide
Choose AdapterJS when you need to support Internet Explorer or Safari versions below 11, when your user base includes enterprise environments with locked-down browsers, or when the Temasys plugin fallback is a requirement. Choose webrtc-adapter when you target only modern browsers, want the most current spec alignment, or are building a greenfield project where legacy support is not a concern. Choose a managed SDK like VideoSDK when you want to avoid managing WebRTC compatibility entirely and focus on application features.
Best Practices for Production Deployments
Deploying AdapterJS in production requires attention to performance, security, and testing strategy. Several practices help ensure a smooth experience for your users across all supported browsers.
Use the Minified Build in Production
AdapterJS ships both debug and minified versions. The debug version includes verbose logging that is useful during development but adds unnecessary file size and console noise in production. Always load the minified version in your production environment and keep the debug version for local development only.
Monitor Browser Usage Analytics
Before committing to the plugin fallback path, analyze your actual browser usage data. If your analytics show that fewer than 2 percent of users are on Internet Explorer or older Safari, the plugin fallback may add complexity and support overhead that outweighs its benefit. Consider showing a browser upgrade prompt for these users instead of investing in plugin support. Conversely, if enterprise contracts require IE support, the plugin is non-negotiable.
Security Considerations
Serve the AdapterJS script over HTTPS alongside your application. Mixing HTTP scripts into an HTTPS page triggers mixed content warnings and can be blocked by modern browsers. If you use a Content Security Policy, ensure your script-src directive includes the CDN domain or your self-hosted script origin. The Temasys plugin, when used, also requires appropriate CSP permissions for plugin loading.
Cross-Browser Testing Strategy
Test your application on real browsers, not just emulators. Set up a testing matrix that covers Chrome, Firefox, Edge, Safari (desktop and iOS), and if applicable, Internet Explorer with the Temasys plugin. Pay special attention to media permission prompts, which vary in timing and behavior across browsers. Test screen sharing separately, as it requires browser-specific extensions on Chrome and has different behavior on Firefox and Safari.
Automated testing for WebRTC is challenging because it requires real media devices and network conditions. Consider using a service like BrowserStack or Sauce Labs for cross-browser testing, and supplement with manual testing on physical devices for iOS Safari, which often behaves differently from desktop Safari.
Definitions Glossary
AdapterJS: A JavaScript shim library developed by Temasys Communications that normalizes WebRTC APIs across browsers and provides plugin-based fallback for browsers without native WebRTC support.
WebRTC shim: A compatibility layer that intercepts WebRTC API calls and translates them into browser-specific implementations, allowing developers to write a single codebase that works across multiple browsers.
Polyfill: A piece of code that provides modern browser functionality to older browsers that do not natively support it, filling gaps in API coverage.
webRTCReady event: A custom event fired by AdapterJS after all browser detection, API wrapping, and plugin initialization is complete, signaling that WebRTC APIs are safe to use.
Temasys WebRTC plugin: A browser extension that provides a native-quality WebRTC implementation for browsers that lack built-in WebRTC support, primarily Internet Explorer and older versions of Safari.
webrtc-adapter: A community-maintained library that normalizes WebRTC APIs across modern browsers with native support, without providing plugin-based fallback for legacy browsers.
Key Takeaways
- AdapterJS normalizes WebRTC API differences across browsers, handling vendor prefixes, missing methods, and plugin-based fallback for legacy browsers like Internet Explorer.
- The webRTCReady event is the critical synchronization point that signals when your application can safely begin using WebRTC APIs after AdapterJS has completed initialization.
- AdapterJS differs from webrtc-adapter primarily in its plugin fallback support, making it the only option when Internet Explorer or older Safari support is required.
- For new projects in 2026, using a managed SDK like VideoSDK eliminates the need for any WebRTC shim by handling browser compatibility, connection management, and media routing internally.
- Production deployments should use the minified build, monitor browser analytics to validate plugin fallback necessity, and maintain a cross-browser testing matrix covering all target browsers.
Conclusion
AdapterJS remains a valuable tool for projects that must support legacy browsers where native WebRTC is unavailable or inconsistent. Its plugin fallback mechanism fills a gap that no other shim addresses, making it indispensable for enterprise and telehealth applications with diverse user bases. For greenfield projects targeting modern browsers only, the webrtc-adapter library or a managed solution like VideoSDK's JavaScript SDK may be a better fit, reducing maintenance burden while providing the same cross-browser compatibility. Explore the VideoSDK JavaScript SDK quickstart to see how a managed WebRTC platform handles browser compatibility without any shim layer. What are you building with WebRTC? Drop a comment below, and check out the VideoSDK Discord community to connect with other developers working on real-time communication projects.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ