Introduction

localStorage works inside Android WebView, but it is not enabled by accident. If a web app inside your WebView cannot persist browser-style key-value data, the first thing to check is whether DOM storage has been explicitly turned on.

What localStorage Depends On

localStorage is part of the browser DOM storage APIs. In Android WebView, the page can use it only if the WebView settings allow the necessary web platform features.

In practice, two settings matter most:

• JavaScript must be enabled if your page uses JavaScript to read and write storage.
• DOM storage must be enabled so localStorage is available.

Basic WebView Setup

Here is a minimal Kotlin example that enables both.

1import android.os.Bundle
2import android.webkit.WebView
3import androidx.appcompat.app.AppCompatActivity
4
5class MainActivity : AppCompatActivity() {
6    override fun onCreate(savedInstanceState: Bundle?) {
7        super.onCreate(savedInstanceState)
8
9        val webView = WebView(this)
10        setContentView(webView)
11
12        webView.settings.javaScriptEnabled = true
13        webView.settings.domStorageEnabled = true
14
15        webView.loadUrl("https://example.com")
16    }
17}

If domStorageEnabled is left as false, web code that expects localStorage may fail silently or behave as if storage is missing.

Verifying It from JavaScript

A quick page script can confirm whether storage is available.

1<script>
2  localStorage.setItem("theme", "dark");
3  console.log(localStorage.getItem("theme"));
4</script>

If you load a page like that into a correctly configured WebView, the stored value should remain available for the same origin across page reloads.

Storage Is Scoped by Origin

localStorage is not one global bucket for the entire WebView. It is scoped to the page origin, which means protocol, host, and port matter. Data written by https://app.example.com is not the same storage used by https://api.example.com or file:// content.

That origin model is important when debugging hybrid apps. If the page seems to lose its data, confirm that you are loading the same origin each time.

Local Files Need Extra Care

Older hybrid apps often loaded HTML through file:// URLs and then expected browser storage to behave like a normal website. That can become awkward because local file origins are not the same as a regular hosted origin.

A cleaner modern pattern is to serve app assets through a proper origin-like mechanism instead of relying on ad hoc local file behavior. The simpler and more web-like the origin setup is, the easier storage behavior is to reason about.

Native App Storage Is Still Different

Do not confuse WebView localStorage with native Android persistence such as SharedPreferences, Room, or files. localStorage is suitable for web-layer state inside the embedded page. It is not the best long-term storage choice for large native app data or business-critical offline state.

If the data belongs to the Android app itself rather than the embedded web UI, native persistence is usually the more robust place to keep it.

Common Pitfalls

• Forgetting domStorageEnabled = true is the most common cause of missing localStorage.
• Enabling DOM storage without JavaScript is not enough if the page uses JavaScript to read and write values.
• Assuming all pages share one storage area ignores origin scoping.
• Treating localStorage as a replacement for native Android persistence can create brittle app architecture.
• Debugging only one URL path while the app actually loads another origin can hide the real storage mismatch.

Summary

• Android WebView supports localStorage when DOM storage is enabled.
• JavaScript usually needs to be enabled as well for web apps that access storage through scripts.
• 'localStorage is scoped by origin, not shared globally across every page.'
• Hybrid apps should be careful about how they load local content and define origins.
• Use native Android storage for app-owned data that should not depend on web-layer behavior.