Rendering web content in Android apps: choosing the right component

Android has supported the web since its early days, shipping with WebView as a component for embedding web content in native apps. The platform also allows developers to embed entire browser engines, though that adds complexity and APK size. For most teams, the practical options are WebView, Custom Tabs, and Trusted Web Activities — each aimed at a different use case.

WebView: best for first-party, embedded content

WebView gives developers access to modern HTML, CSS, and JavaScript inside an Android app. Content can ship inside the APK or be hosted remotely. It is one of Android's most flexible components, powering ad services like AdMob and packaging HTML5 games that rely on APIs such as WebGL. When an app needs a layout component rendered alongside native UI, WebView is the natural fit.

However, WebView is primarily a web UI toolkit, not a browser framework. It does not support all features of the web platform. APIs that already have an OS-level alternative (for example, Web Bluetooth) or that require browser UI (such as push notifications) may be unsupported. As the web platform evolves, that gap widens. Because developers cannot control which features third-party content will use, WebView is a poor choice when opening external sites.

Security gaps in WebView for untrusted content

WebView grants the embedding app full access to rendered content, including cookies and the DOM — powerful capabilities that require high user trust. For untrusted third-party content, WebView lacks security features that modern browsers rely on.

Modern browsers isolate untrusted content using a multi-process architecture and site isolation. Without multi-process rendering, a web page crash can take down the entire application, and a vulnerability can be exploited against the device. Before Android 8.0 Oreo, the WebView renderer ran in the same process as the embedding app. On newer, capable devices, the renderer runs in a separate process — but all pages and WebView instances still share one process, making full site isolation impossible. These limitations expose users of WebView-based browsers to vulnerabilities like Meltdown and Spectre, which can be used to steal cookies, banking details, and personal information.

Browsers also invest heavily in secure UI indicators, but WebView lacks an API for checking connection security. Without it, developers cannot reliably build trustworthy indicators; a URL in an address bar might not match the page actually displayed, even over HTTPS. Embedding a full browser engine avoids these problems but is complex, time-consuming, and inflates application size.

Custom Tabs, introduced in Chrome 45, lets developers use a tab from the user's default browser as part of their own app. Originally known as Chrome Custom Tabs, it is now an Android API supported by most major browsers, including Chrome, Firefox, Edge, and Samsung Internet. Developers can customize the toolbar color, action buttons, and transition animations, making third-party navigation feel more seamless.

Because Custom Tabs is powered by the user's actual browser, it shares storage with that browser. Users stay logged in to sites across different apps that open in-app browsing sessions, without needing to re-authenticate each time. Custom Tabs also supports every web platform feature and API the underlying browser supports — something WebView cannot offer.

Trusted Web Activities: fullscreen PWAs

Progressive Web Apps bring platform-app behaviors to the web, and developers have wanted to reuse those experiences inside Android apps. Custom Tabs, designed for third-party content, always displays a toolbar with the URL and a security lock icon — fine for external sites, but a barrier when an app wants to show its own experience as part of the operating system.

Trusted Web Activities, introduced in Chrome 72, solve that problem. The protocol resembles Custom Tabs, but adds APIs to verify — through Digital Asset Links — that the developer controls both the Android app and the URL being opened. When ownership is confirmed, the URL bar is removed. Trusted Web Activities also provide APIs for splash screens and for delegating web notifications to Android code, with Play Billing support on the way. Since these activities are intended for PWAs, quality criteria apply to the web experiences opened inside them.

Choosing among the options

  • WebView is suitable when an application needs HTML, CSS, and JavaScript inside a native layout and does not rely on advanced web capabilities like push notifications or Web Bluetooth. It works well for displaying first-party content the app controls and trusts.
  • Custom Tabs is the recommended approach for in-app browsers that open third-party content designed for the modern web platform.
  • Trusted Web Activity should be used when rendering a developer's own Progressive Web App fullscreen inside an Android application, either as the sole activity or alongside other native activities.

Developer feedback has shown a desire for a solution that combines Custom Tabs' platform compatibility with WebView's flexibility, such as DOM access or JavaScript injection. Custom Tabs is effectively a tab rendered by the user's browser, so privacy and security expectations the user holds toward that browser make those features impossible. Google's Web on Android team is exploring and experimenting with alternatives to address these use cases.