ERR_CLEARTEXT_NOT_PERMITTED in a WebView means Android blocked a request to a plain http:// address. Starting with Android 9 (API level 28), apps refuse cleartext traffic unless they opt in. The lasting fix is to serve the page over HTTPS; the stopgap is to allow cleartext for one named domain in a network security config.
Why the WebView shows ERR_CLEARTEXT_NOT_PERMITTED
The WebView shows ERR_CLEARTEXT_NOT_PERMITTED because your app’s network rules forbid unencrypted HTTP. Android’s network security configuration docs put it directly: “Starting with Android 9 (API level 28), cleartext support is disabled by default.”
The Android 9 behaviour changes put it in code terms: if your app targets Android 9 or higher, isCleartextTrafficPermitted() returns false by default.
The WebView follows those app rules. The <application> element reference notes that WebView “honors this attribute for applications targeting API level 26 and higher.” That’s why the same site opens fine in Chrome and fails inside your app.
The blocked request isn’t always the page itself. An image, script, API call or redirect on http:// can trigger it too. Kinsta’s guide lists the safest option first: configure the site that returns the error to use HTTPS.
Which fix to use
The right fix for ERR_CLEARTEXT_NOT_PERMITTED depends on who controls the http:// address.
| Situation | Fix | Why |
|---|---|---|
| Your own website still runs on http:// | Move it to HTTPS | Removes the error and the risk |
| A third-party resource only offers http:// | Allow that one domain in a network security config | Keeps the rest of the app on HTTPS |
| A test server during development | Allow its domain in a debug-only config | Android names debugging as the usual reason for exceptions |
| You want a one-line switch | android:usesCleartextTraffic="true" |
Works now, but Android is deprecating it |
Fix 1: serve the site over HTTPS
Serving the site over HTTPS fixes ERR_CLEARTEXT_NOT_PERMITTED without changing the app’s security at all. Once every request uses https://, there’s no cleartext to block.
A certificate doesn’t have to cost anything. Let’s Encrypt describes itself as a certificate authority “that provides free TLS certificates, making it easy for websites to enable HTTPS encryption.” Many hosts install one for you.
Then:
- Change the start address in your app from
http://tohttps://. - Look for old
http://links to images, scripts and APIs in your pages. Each one can still fail on its own.
My take: if the site is yours, do this and nothing else. Every other fix keeps an unencrypted path open.
Fix 2: allow one domain in a network security config
A network security config lets your app allow cleartext for a named domain while blocking it everywhere else. Android describes the feature as a way to customize network security “in a safe, declarative configuration file without modifying app code.”
Create res/xml/network_security_config.xml with a domain-config for the domain you need. This is Android’s own example, with its sample domain:
<network-security-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">insecure.example.com</domain>
</domain-config>
</network-security-config>Then point to it from the manifest. Android’s docs say “You must include an entry in your app’s manifest to point to this file”:
<application android:networkSecurityConfig="@xml/network_security_config" ... >Replace insecure.example.com with the real domain. Leave the base configuration alone, so every other domain still requires HTTPS. Android’s cleartext risk guide recommends exactly this shape: enforce HTTPS, “with exceptions for only the specific domains required (usually for debugging purposes).”
Why android:usesCleartextTraffic is a short-term fix
The android:usesCleartextTraffic flag is the fix most answers still give, but Android now marks it for removal. It sets whether the app “intends to use cleartext network traffic, such as cleartext HTTP.”
Three details from the <application> reference matter:
- Its default is “true” for apps that target API level 27 or lower, and “false” for API level 28 or higher.
- The flag “is getting deprecated and will be ignored for apps targeting API levels 38 and above.”
- It “is ignored on Android 7.0 (API level 24) and above if an Android Network Security Config is present.”
That last point catches people out. If your project already has a network security config, setting the flag does nothing. Target API level 38 or higher and it stops working. A per-domain config doesn’t have either problem.
It also opens every domain at once. Android warns that with cleartext allowed, “anyone monitoring network traffic can see and manipulate the data that is being transmitted.”
How to check the fix worked
You’ve fixed ERR_CLEARTEXT_NOT_PERMITTED when the page and all its resources load in the app on a real phone. Test on a device running Android 9 or newer, since older targets allowed cleartext by default.
Open each section of the app, not only the home page. A login form, a download link or a payment page can still call an old http:// address. If downloads are the part that fails, read why file downloads don’t work in a WebView. That one has a different cause.
What this means for no-code WebView apps
In a no-code WebView app you usually can’t edit the manifest, so HTTPS is the only fix you control. That’s the limitation of builders: the network rules ship inside the template.
WebToAPK Free asks for a complete HTTPS address for every website section, so an http:// start page can’t be entered at all. Its apps need Android 8.0 or newer, and it doesn’t promise every website works in a WebView. Test every page on a phone before you publish. The website-to-APK guide walks through the build.
If you’re new to wrappers, start with which apps use WebView and how to convert a website into an Android app. Before you upload, see whether Google Play rejects WebView apps.
FAQ
Why does my site load in Chrome but show ERR_CLEARTEXT_NOT_PERMITTED in my app?
Your app follows its own network security rules. Starting with Android 9 (API level 28), apps block cleartext HTTP by default, so a plain http:// address fails inside the app’s WebView.
Is android:usesCleartextTraffic=“true” still a good fix?
It works today but it’s a short-term fix. Android’s docs say the attribute is being deprecated and will be ignored for apps targeting API levels 38 and above, and it’s ignored when a network security config is present.
Is allowing cleartext traffic safe?
Not for real user data. Android warns that anyone monitoring network traffic can see and manipulate cleartext data, so limit any exception to the specific domains you need.
How do I get HTTPS for my website for free?
Let’s Encrypt is a certificate authority that provides free TLS certificates, and many hosts can set one up for your domain.
Can a no-code WebView builder load an http:// website?
It depends on the builder. WebToAPK Free requires a complete HTTPS address for website sections, so the site needs HTTPS first.