A Trusted Web Activity (TWA) is an Android app that opens your own Progressive Web App full screen in the user’s browser, usually Chrome, with no address bar. You only need one if you own the website, it already works well as a PWA, and you want browser features such as shared logins inside the app. If you want to bundle offline HTML, wrap a site you don’t control, or avoid hosting a verification file, a WebView app is the simpler route.
What a Trusted Web Activity is
A TWA is a way to open your web app from an Android app using a protocol based on Custom Tabs, according to Android’s TWA overview. Your app doesn’t draw the page. The user’s browser does, as it would in a normal tab, only full screen.
“Trusted” means the app and the site come from the same developer. Android checks that with Digital Asset Links, a small JSON file on your domain that names your app. The overview also says TWAs are available in Chrome on Android version 72 and above.
Because the browser renders the page:
- Your app can’t touch the page. The host app has no direct access to the web content or to cookies and localStorage.
- Screens are all web or all native. Each activity, meaning each screen, is either fully provided by the web or by an Android activity. You can’t put a native button on top of the web page.
Trusted Web Activity vs WebView vs Custom Tab
The three options differ in who renders the page and whose cookies it uses. A WebView is part of your app. A Custom Tab and a TWA belong to the browser, and a TWA is simply a Custom Tab with the browser UI removed for a site you’ve proven you own.
A Chrome engineer put the main difference plainly in an android-browser-helper issue: TWAs share state with the user’s browser, so if you’re logged in there, you’re logged in in the TWA. WebViews don’t share that state. The same comment notes that tools like Cordova and Ionic package sites in a WebView, which is not technically a TWA.
| WebView app | Custom Tab | TWA | |
|---|---|---|---|
| Who renders the page | The WebView inside your app | The user’s browser | The user’s browser |
| Browser UI visible | No | Yes, a toolbar | No, once verified |
| Shares cookies and logins with the browser | No | Yes | Yes |
| Sites it can show full screen | Any you load | Any, with toolbar | Only sites you own |
| Can show bundled offline HTML | Yes | No | No |
| Your app can inject JavaScript | Yes | No | No |
| Needs a file hosted on your domain | No | No | Yes, assetlinks.json |
Chrome’s Custom Tabs page is fair to both sides. It says WebViews don’t support every web platform feature and don’t share state with the browser. It also says WebView is the right choice when you exclusively host your own content in the app or need to inject JavaScript.
Do you need a TWA?
You need a Trusted Web Activity only when three things are true: you control the domain, the site is already a solid PWA, and you want it to behave like the user’s own browser. Otherwise a TWA is just extra setup.
A TWA is a good fit when:
- Your users already sign in on your site in Chrome and you want that session to carry into the app.
- Your site relies on browser features that a WebView may not support.
- You’d rather let the browser update the web engine. The Android overview notes that browsers update independently of Android and your app, which also keeps the APK small.
A WebView app is the better fit when:
- You want to ship self-contained HTML that works with no connection.
- Every phone should behave the same, whatever browser the user has installed. The issue thread above makes this exact point.
- Your host won’t let you add files to the site’s
/.well-known/folder, for example on a hosted site builder.
My view: if your site is a real PWA on your own domain, build the TWA first. You get the browser’s logins and autofill for free. If you’re wrapping a simple site or a set of HTML pages, skip the TWA and its verification file. For a longer comparison, see PWA vs WebView app.
What a TWA needs
A TWA needs a supporting browser, a PWA-quality site and a verified link between app and domain.
- Browser support. Chrome 72 or newer. The quick start guide says the app tries the user’s default browser first, then any installed browser that supports TWAs, and finally falls back to Custom Tabs mode.
- PWA checks. The Android overview expects TWAs to meet the same Add to Home Screen requirements, which you can audit with Lighthouse.
- Digital Asset Links. The integration guide says the file must sit at
/.well-known/assetlinks.jsonat the root of the domain, the only place Chrome looks. - Build tooling. Bubblewrap is a Node.js command-line tool that generates the Android project (
npm i -g @bubblewrap/cli, thenbubblewrap initandbubblewrap build). PWABuilder offers a web interface that runs Bubblewrap for you.
Why your TWA shows a URL bar
A TWA shows a URL bar when the browser can’t verify your Digital Asset Links. The quick start says that if verification fails, the browser falls back to displaying your site as a Custom Tab, with browser UI at the top of the page. The app still opens, so people often ship it without noticing.
The most common cause is the wrong signing fingerprint. Chrome’s Android guide for web developers explains the trap. If you opt in to Play App Signing, the key Bubblewrap generated becomes your upload key, and Google signs the app with a different key. The fingerprint in assetlinks.json has to match the key users’ copies are signed with, so a file that only lists your upload key fails on installs from Google Play.
To check:
- Connect a test phone and run
adb logcat -v brief | grep -e OriginVerifier -e digital_asset_links. - Open the app. A mismatch logs a line such as
Statement failure matching fingerprint. - Copy the app signing key’s SHA-256 fingerprint from Play Console and add it to
sha256_cert_fingerprints. You can list both keys. - Check the JSON. The same guide warns that Chrome’s parser is strict, so a trailing comma can break it.
If the two keys are new to you, upload key vs app signing key explains which fingerprint goes where, and Play App Signing covers whether to enrol.
Publishing a TWA on Google Play
A Trusted Web Activity publishes on Google Play like any other Android app. Bubblewrap produces a signed project, and the Chrome guide notes that Google Play has required new apps to use the Android App Bundle format since August 2021.
Review rules don’t change because you used a TWA. It’s still your website on screen, so the same thin-content risks apply. Read do WebView apps get rejected by Google Play before you submit.
Where WebToAPK Free fits
WebToAPK Free does not build Trusted Web Activities. It packages a hosted HTTPS website, self-contained HTML or text pages into a WebView app, and gives you a signed APK for testing and an AAB for a store submission. Projects and signing keys stay in your browser, and the tool is free with no account.
That’s the WebView column of the table above. Bundled HTML and text sections work offline, and you don’t need to host an assetlinks.json file. The limitation is the flip side: a WebView app doesn’t share logins with Chrome, the tool doesn’t support push notifications, and sign-in, downloads and permissions can behave differently than in a browser. If those matter more to you than offline content, use Bubblewrap. If not, the website to APK guide walks through the WebView route.
FAQ
Is a Trusted Web Activity the same as a WebView?
No. A WebView is a component inside your app that renders pages itself. A TWA hands the page to the user’s browser, such as Chrome, which shows it full screen and shares its cookies and logins.
Why does my TWA show a URL bar?
The browser could not verify that your app and site belong together, so it fell back to a Custom Tab with browser UI. The usual cause is a missing or wrong SHA-256 fingerprint in /.well-known/assetlinks.json, often the Play App Signing key.
Can I make a Trusted Web Activity for a website I don’t own?
No. Google’s quick start says the capability is restricted to websites you own, and you prove ownership by hosting a Digital Asset Links file on the site.
Which Chrome version supports Trusted Web Activities?
Chrome on Android version 72 and above. If the user’s browser doesn’t support it, the app falls back to a Custom Tab with a toolbar.
Can I publish a Trusted Web Activity app on Google Play?
Yes. Tools like Bubblewrap and PWABuilder produce an Android project you sign and upload like any other app, as an Android App Bundle.
Sources
- Overview of Trusted Web Activities, Android Developers
- Quick start to Trusted Web Activities, Chrome for Developers
- Trusted Web Activity integration guide, Chrome for Developers
- Android concepts for web developers, Chrome for Developers
- Overview of Android Custom Tabs, Chrome for Developers
- Breakdown on supported features at browsers, android-browser-helper issue