Offline AI in a Browser: How PWAs, WebGPU, and Local Models Work

The five pieces an offline browser AI app needs

It is tempting to reduce browser AI to a single feature check: if navigator.gpu exists, the app must work offline. In reality, an offline chat depends on a chain of independently fallible pieces. The browser must be able to reopen the interface, the runtime must load, the exact model and tokenizer must still exist in local storage, the device must have sufficient resources, and the application must route a prompt to that local runtime rather than a network endpoint.

A Progressive Web App helps with installation and offline delivery, but it is an application packaging and lifecycle pattern, not an inference engine. WebGPU exposes modern GPU computation to web code. WebAssembly provides a portable binary execution target and can support CPU-based inference. Storage APIs retain application records and large artifacts. A production local-AI PWA combines these capabilities and supplies fallbacks and recovery when one is unavailable. [1] [2]

The layers behind an offline AI PWA

What a service worker contributes

A service worker is a worker that can receive fetch events before a controlled page makes its network request. It can return a cached response, request a fresh response, or provide an offline fallback. The W3C specification explicitly provides a request-and-response store to support offline-enabled web applications. [1]

That power has to be programmed carefully. A service worker does not automatically know which assets form a safe offline release. The app must choose its shell files, download them, verify that installation succeeded, and decide when a waiting update can replace the active version. Google's PWA guidance recommends precaching the minimal assets required to render the offline experience and caching other assets as needed, because aggressive precaching consumes network and device storage. [3]

For local AI, the distinction between shell and model is essential. A small versioned shell can be installed atomically. Large model and optional runtime packs should normally be explicit downloads with progress, integrity verification, cancellation, and resumability. If every model is bundled into the service-worker install, opening the site can trigger an enormous hidden download and one missing file can invalidate the whole update.

What WebGPU does and does not do

WebGPU gives web applications a modern interface to GPU rendering and general-purpose compute. A compatible browser exposes an adapter representing available graphics hardware; the application requests a logical device, inspects supported limits and features, and submits work through validated pipelines. The API is available only in secure contexts, and MDN continues to mark it as not universally available across widely used browser configurations. [2] [4]

WebGPU is therefore an acceleration opportunity, not a universal compatibility promise. The API may be absent, requestAdapter may return no adapter, a requested limit may be unavailable, or the device can be lost while the app is running. Even when WebGPU works, a particular inference library and model format must implement a compatible backend. Another model may use WebAssembly and CPU threads instead. [4]

A responsible app performs capability checks before presenting a model as usable. It should distinguish 'this browser lacks WebGPU' from 'this model needs a different runtime' and from 'there is not enough memory.' It should also avoid claiming a speed number measured on another phone. Browser version, operating system, GPU driver, model quantisation, context size, temperature, and thermal state all affect observed performance.

Where the model is stored

Large browser model files are commonly kept in origin-scoped storage rather than ordinary cookies or localStorage. IndexedDB can hold structured records and blobs, while the Origin Private File System can provide file-like private storage. Cache Storage is appropriate for request-and-response assets such as the application shell. Each mechanism has different transaction, streaming, and integrity characteristics.

Local does not mean permanent. Browsers enforce quotas and may evict best-effort storage under pressure. The StorageManager persist method lets an origin request persistent storage, but the browser can decline, and browser-specific rules still apply. Users can also clear site data or uninstall the PWA. An offline AI app should report storage health, retain a verified completion marker, and offer an encrypted backup for irreplaceable conversations rather than pretending browser storage cannot disappear. [5]

Integrity matters because model files are both large and executable inputs to a native-speed runtime. A robust downloader pins an immutable source revision, checks the exact byte count and cryptographic hash, commits an installed state only after verification, and resumes partial data without confusing it with a complete model. A button labelled Download must either move bytes or show a specific failure.

Why first use still needs the internet

An offline-capable PWA cannot conjure its initial files without a delivery path. The first browser visit obtains HTML, JavaScript, styles, worker code, and other shell assets. The chosen model may be hundreds of megabytes or more and should be downloaded only after the user reviews its size, license, and device requirements. Updates and a newly selected model also require connectivity.

This produces a useful distinction: offline-ready is a verified state, not a marketing adjective. The app should know whether a complete shell is active, a model is verified, a runtime pack is present, and the selected model can load. Until then, it should say what remains to download. Google's PWA documentation similarly notes that service workers are not in control on the first visit and should be treated as optional rather than required for the first page to function. [6]

1. Open the PWA online and let the current shell install completely.
2. Choose one compatible model after reviewing its requirements and license.
3. Wait for download and integrity verification to finish.
4. Activate the model and send a short online smoke-test prompt.
5. Close and reopen the installed PWA to confirm shell and model persistence.
6. Enable airplane mode and send a new prompt rather than replaying cached text.

Offline does not mean background-proof

Mobile browsers can suspend a page when it is backgrounded, the screen locks, or the operating system needs resources. A service worker is event-driven and can be terminated between events; it is not a permanent background compute process. Long-running model inference normally belongs to the controlled page or a worker associated with it, so leaving the app can interrupt a generation. [1] [6]

The correct response is durable recovery, not an impossible guarantee. The app can checkpoint partial output, label an interrupted run, restore the composer to a usable state, and offer Retry or Continue where the runtime supports it. It must not leave a Stop button visible when no generation is active. Native Android may have different lifecycle tools, but it is still subject to memory pressure and operating-system policy.

A practical offline browser AI test

A meaningful test separates app caching from inference. While online, install the PWA, download exactly one model, activate it, and send a short prompt. Reopen the app before disconnecting; this catches a model selection that existed only in memory. Then enable airplane mode, create a new chat, and ask for a unique response. Capture whether output begins, whether Stop works, and whether another prompt can be sent afterwards.

Repeat after a browser restart, not only a tab refresh. Check the model manager while offline, inspect any storage warning, and verify that optional web search reports a clear connectivity boundary rather than silently falling back. Finally, remember that one passing test covers one browser, version, device, model, and storage state. It does not prove universal PWA compatibility.

• Use a fresh prompt whose answer could not already be cached.
• Confirm the selected model name before and after restart.
• Measure time to visible output, not only total completion time.
• Stop a response and confirm the composer recovers.
• Distinguish model failure, storage eviction, and missing network-dependent features.

CuriousLM's browser boundary

CuriousLM's PWA is designed to keep ordinary conversations, projects, files, indexes, and inference on the current origin and device. It does not automatically download a model. The user chooses an artifact, the app verifies it, and the model manager activates it in the current app context. Browser runtimes can differ by model, so WebGPU is not advertised as a universal requirement or a universal acceleration result.

The PWA still needs the network for first delivery, updates, and explicit model or optional runtime downloads. Tavily search is a separate, user-confirmed network action using the user's key. Response reports are separately previewed and confirmed. Browser storage can be removed, and a forgotten local vault or backup passphrase cannot be recovered. Those limitations are part of the offline contract, not footnotes.