For years, Edge AI has been associated with specialised devices: smartphones, cameras, industrial gateways, embedded computers and local servers. Google's release of LiteRT.js widens that definition.

The browser can now host a practical Edge AI runtime.

LiteRT.js allows machine-learning models to run locally inside a web browser, using the CPU, GPU or, as support develops, dedicated neural-processing hardware already present on the user's device. A web application can therefore process some images, audio, documents and interactions without sending each input to a remote inference service.

Browser-based machine learning is not new. What LiteRT.js adds is a production-focused JavaScript binding to Google's wider on-device runtime, a shared .tflite model format and direct paths to several forms of browser hardware acceleration. That combination could make local AI easier to deploy through the web.

What is LiteRT.js?

LiteRT is Google's on-device machine-learning runtime, formerly known as TensorFlow Lite. It supports model execution across mobile, desktop, embedded and other edge environments. LiteRT.js brings that runtime to web applications through JavaScript and TypeScript.

Developers can load and execute .tflite models in the browser. Before deployment, models created in PyTorch, JAX or TensorFlow can be converted to LiteRT format. The same model format can therefore support web, mobile and other edge deployments, subject to operator and platform compatibility. LiteRT.js can also fit into existing TensorFlow.js pipelines by accepting and returning TensorFlow.js tensors at the model boundary.

Under the hood, LiteRT.js can use three browser execution paths:

• WebAssembly (Wasm) for CPU inference. LiteRT's CPU path uses XNNPACK, an optimised neural-network library, mapped to WebAssembly.
• WebGPU for GPU inference. WebGPU gives web applications access to modern GPU compute capabilities for highly parallel workloads.
• WebNN for hardware acceleration. The emerging WebNN API gives browsers a common interface for neural-network acceleration. Depending on the browser and device, its implementation may use available hardware such as an NPU. Google described WebNN support as experimental in Chrome and Edge when it announced LiteRT.js in July 2026.

It would therefore be misleading to describe LiteRT.js as being built exclusively on WebAssembly. Wasm brings Google's native runtime and its CPU optimisations into the browser. WebGPU and WebNN provide additional routes to GPU and NPU acceleration.

WebAssembly is a compact binary instruction format for a stack-based virtual machine. It allows code compiled from languages such as C and C++ to run in modern browsers at speeds suitable for demanding applications. It works alongside JavaScript rather than replacing it: JavaScript manages the application, while Wasm can execute performance-sensitive parts of the runtime.

The browser is becoming an Edge AI platform

The edge is not defined by one type of device. It is the part of a system where data is processed close to the user, sensor or operational environment.

A compatible browser running on a laptop, tablet, smartphone or local workstation can host inference at that position. A LiteRT.js deployment might follow this pattern:

Web application
      ↓
Cached runtime and model
      ↓
On-device inference
      ↓
Local result or action
      ↓
Optional cloud synchronisation, escalation or review

The cloud still has an important role. It can train and evaluate models, distribute updates, coordinate users, consolidate analytics and handle workloads that exceed the device's capacity. But it no longer needs to process every interaction.

This is Edge AI delivered through the distribution model of the web.

Why LiteRT.js matters for Edge AI

1. Local AI can be deployed without a separate native application

The web's main advantage is reach. A web application can serve users across operating systems without requiring separate Android, iOS, Windows and macOS interfaces.

LiteRT.js adds local inference to that shared application layer. Because it uses the same .tflite format as the wider LiteRT ecosystem, an organisation may also be able to reduce the number of model formats and conversion pipelines it maintains across web and native products.

This does not remove the need for platform testing. Browser support, available memory, hardware acceleration and performance will vary. It does, however, offer a more unified route from model development to deployment.

2. Sensitive data can remain closer to the user

Many AI applications send every input to a server for processing. Client-side inference can remove that round trip for suitable workloads.

An application could classify an image, generate an embedding, inspect a document or analyse an audio sample inside the browser. This may be useful when working with identity documents, internal records, student information, field observations or other data that should not leave the device unless necessary.

Local inference does not make an application private by default. Developers still need to manage permissions, browser storage, analytics, logs, model outputs and any data later synchronised with a server. They also need to explain clearly what stays on the device and what does not.

The architectural advantage is narrower but still important: sending data elsewhere becomes a design decision rather than a requirement of every prediction.

3. Applications can respond without a server round trip

Local inference can reduce the delay between an input and a result, especially when the network is slow or distant from the inference service. That matters for interactive tasks such as object detection, audio processing, image enhancement, document analysis and assistive interfaces.

Google's launch demonstrations included browser-based vector search, object detection, depth estimation and image upscaling. Its published benchmark charts compared LiteRT.js with ONNX Runtime and reported speedups of up to about three times on selected computer-vision and audio models. Google also reported GPU or WebNN execution between 5 and 60 times faster than its CPU path for selected workloads.

Those numbers need context. Google ran the tests on a 2024 MacBook Pro with Apple M4 silicon in a controlled browser environment. Results will vary with the model, browser, available accelerator, drivers, power settings and thermal conditions. The broader point is not that every device will achieve the same speed. It is that useful AI inference can increasingly happen where the user interaction occurs.

4. Selected AI functions can work with intermittent connectivity

A LiteRT.js application normally needs an initial connection to retrieve the web application, runtime and model. If those resources are cached correctly, developers can build local-first or offline-capable workflows around them.

A field worker could classify an image, check the quality of a photograph, validate a form or flag a possible equipment fault without waiting for a reliable connection. The application could store the result locally and synchronise it later.

This model is not independent of infrastructure. Applications and models still need distribution, version control, updates and governance. Browser storage policies may also remove cached resources, and offline behaviour must be tested on the devices people actually use. Even with those constraints, the immediate task does not always have to wait for the cloud.

5. Cloud inference can be reserved for the work that needs it

When inference runs in the browser, the user's device supplies the compute. Applications with many small, repeated interactions may be able to reduce the number of requests sent to central AI infrastructure.

That does not make Edge AI free. Organisations still pay for application development, model optimisation, testing, distribution, monitoring, support and any cloud services that remain. Users' devices also consume memory, processing capacity and energy.

The opportunity is to spend central compute more selectively. A compact local model can handle frequent and predictable tasks, while the application sends complex, ambiguous or high-risk cases to a larger cloud model or a human reviewer.

Why this matters in African digital environments

The implications are especially relevant where connectivity quality, device capability and cloud costs vary sharply between users and locations.

Schools, health programmes, financial-service providers, agricultural projects, logistics teams and public institutions already use browser-based systems because they are easier to distribute than separate native applications. These systems often run across a mixed estate of laptops, tablets and smartphones, sometimes with unreliable or expensive connectivity.

LiteRT.js creates a path for adding local intelligence to those systems. Possible applications include:

• crop or plant-condition classification for agricultural field teams;
• document classification and local redaction before upload;
• data validation during offline or intermittently connected field research;
• equipment and infrastructure inspection using computer vision;
• semantic search across downloaded educational or operational material;
• speech, audio or language classification for accessibility tools;
• image-quality checks before field data is submitted;
• local recommendations within educational applications; and
• Detection of incomplete or inconsistent form entries.

The strongest early use cases may not require large generative models. Compact vision, audio, classification, and embedding models can solve narrow, repetitive problems while fitting within the memory and processing limits of a wider range of devices.

For practical AI adoption, model choice should begin with the decision to be supported and the conditions under which it is made. The largest model is rarely the best choice when it cannot run reliably on the available hardware or network.

A practical hybrid architecture

LiteRT.js strengthens the case for hybrid AI systems. Instead of choosing between cloud AI and Edge AI, a system designer can place each part of a workflow where it works best.

The browser may be suitable for:

• immediate classification;
• object or anomaly detection;
• embedding generation;
• local content search;
• data validation;
• privacy-sensitive preprocessing; and
• offline or low-connectivity workflows.

A local or cloud server may be better for:

• application and model updates;
• central reporting and analytics;
• coordination across users or locations;
• long-running workflows;
• large-model inference;
• model training and evaluation;
• governance, audit and monitoring; and
• cases that require more context or human review.

This division keeps the application responsive near the user while retaining the coordination and computing capacity of central infrastructure. The cloud does not disappear. The system uses it where it adds the most value.

The limitations still matter

LiteRT.js does not mean every machine-learning model belongs in the browser.

Model size affects download time, memory use and startup latency. LiteRT.js also documents a 2 GB Wasm memory limit. Low-cost devices may struggle with intensive workloads, and application code remains responsible for model-specific preprocessing and post-processing. WebGPU and WebNN availability differs across browsers, operating systems and hardware. An NPU may exist on a device without being accessible through the browser.

LiteRT.js lets developers select Wasm, WebGPU or WebNN as an accelerator. Its web guide states that unsupported WebGPU and WebNN operations can fall back to CPU. The repository adds an important WebGPU qualification: browsers with JavaScript Promise Integration can delegate unsupported operations individually to Wasm, while other environments may fall back to Wasm for the whole model. Either path can alter performance and power use. Applications still need capability detection, realistic performance budgets and clear behaviour when local inference is too slow or fails.

Production teams should test:

• initial model and runtime download size;
• browser, operating-system and hardware compatibility;
• memory, storage, battery and thermal behaviour;
• model quantisation and its effect on accuracy;
• caching, offline operation and update behaviour;
• model integrity and exposure of proprietary model assets;
• observability that does not collect unnecessary user data;
• fallback and recovery paths; and
• performance on the devices used by the intended audience, not only on development hardware.

Moving inference out of the data centre does not remove infrastructure work. It shifts part of that work into a diverse and less predictable device environment.

From browser-based AI to local decision support

LiteRT.js connects the browser to Google's on-device AI stack. WebAssembly brings optimised CPU execution to the web, while WebGPU and the emerging WebNN API open device-dependent paths to GPU and neural-network acceleration.

That makes the browser useful as more than an interface. It can process sensitive inputs locally, respond without a server round trip, support selected offline workflows and act as the near-user layer of a larger hybrid system.

The practical question is no longer only whether a model can run in the browser. System designers should ask which decisions need to happen locally, what data should remain on the device and when the application should involve the cloud or a human reviewer.

That is where LiteRT.js becomes relevant to Edge AI: not as a replacement for cloud infrastructure or specialised edge hardware, but as another place to put intelligence when proximity, privacy and responsiveness matter.