How do you plan reliable browser AI with LiteRT.js?

A photo-upload page needs to warn visitors when an image is too dark, blurred, or too small before they submit it. The team wants the first quality check to run in the browser so the original photo does not need to leave the device. The product still needs an honest plan for unsupported hardware, failed model loading, and surrounding telemetry.

Google announced LiteRT.js on July 9, 2026 as a JavaScript binding for running compatible models in web browsers. It brings the LiteRT runtime to the web through WebAssembly and adds accelerator paths for graphics and neural hardware. That capability creates a local option, not a universal guarantee.

Define the photo-quality contract first

State what the feature must decide and what it must never imply. Our check evaluates brightness, blur, and minimum dimensions, then returns an actionable message. It does not identify a person, diagnose image content, or guarantee that a later upload will succeed.

Define the supported input size, model version, output threshold, and maximum wait before implementation. Specify whether the original photo remains local during the check. List every separate network path, including analytics, error reporting, model downloads, and the final upload after consent.

This bounded contract follows the same practice as vibe coding: ask for one observable feature, then test its complete behavior. Do not begin with a claim that browser AI is private or fast; those properties depend on the actual system.

Detect capabilities before loading the model

LiteRT.js can use WebAssembly with CPU acceleration, WebGPU for supported graphics processors, and an emerging WebNN path for neural processing units. Browser and device support vary, so capability detection belongs at the start of the flow. A feature should not download a large model before it knows which execution path can compile it.

For the photo check, detect the available backend and compare it with the feature's supported matrix. Record the chosen path for diagnostics without recording the photo. If no supported path exists, show the declared fallback immediately.

Do not use browser brand alone as a capability test. Operating system, driver, hardware, browser version, and policy settings can change accelerator availability. Test the API and handle rejection at runtime.

Load and compile with visible states

The model and runtime are product assets with download, cache, and compilation behavior. Show progress that describes the current stage, provide cancellation, and set a timeout based on measured devices. A blank spinner gives no useful recovery path.

Handle first visit, cached return, interrupted download, corrupted asset, compilation failure, and low-memory termination. Keep the rest of the page usable while loading when the product allows it. If the quality check blocks submission, explain why and offer a supported alternative.

Model size affects both initial wait and memory. Quantization can reduce size, but it may also change output quality. Validate the exact exported model instead of assuming that conversion preserves every threshold.

Run the check locally and explain its result

After a visitor selects a photo, decode it at a bounded resolution and prepare the model input. Run the selected backend, release intermediate resources, and convert the output into three understandable checks. The interface might say “Increase lighting,” “Hold the camera steady,” or “Choose a larger image.”

Avoid presenting a model score without context. A number such as 0.63 does not tell a visitor what to change. Connect each threshold to an action and allow the visitor to submit a replacement photo.

Test repeated selections, cancellation, page navigation, and several image formats. Ensure that one failed run does not leave stale success from the previous photo. This state work is as important as the inference call.

Declare the fallback before a failure occurs

Our primary fallback lets the visitor skip the local check and continue to the existing upload review, with a notice that quality will be checked later. Another product might offer a remote check after explicit consent. Neither path should activate silently.

The fallback message should name what changes. If a remote service receives the photo, explain the destination, purpose, retention, and available alternative before transfer. If the feature cannot continue, let the visitor cancel without losing unrelated form data.

Build the fallback in the first release rather than treating it as future cleanup. Unsupported accelerators, model failures, memory pressure, and corporate browser policies are normal operating states. A product without a fallback has not completed its capability contract.

Audit every data path before making privacy claims

Local inference can keep photo pixels out of the model server path. It does not disable page analytics, content-delivery logs, crash reporting, authentication, or the final upload. Review each path separately and document only what the implementation proves.

Avoid logging raw tensor values, file names, image metadata, or generated thumbnails unless the product needs them and has an approved policy. Keep diagnostic events limited to capability, model version, backend, duration, and coarse failure code where possible. Confirm that those fields cannot identify the photo or visitor beyond the stated purpose.

If privacy is central to the product, inspect the browser network log during a real run. A claim based only on architecture diagrams can miss third-party scripts or a remote fallback. The same evidence discipline improves your first good prompt because it replaces broad promises with checks.

Measure performance and output quality on target devices

Google published vendor benchmarks across CPU, WebGPU, and WebNN configurations. Those results come from documented test devices and workloads. Your feature uses a different model, image size, browser state, thermal condition, and audience.

Measure cold download, cached startup, compilation, first inference, repeated inference, peak memory, battery impact, and failure rate. Test low-end and older devices that remain inside the supported audience. Repeat runs after the device warms up because thermal throttling can change latency.

Performance alone is not enough. Compare brightness and blur decisions against a labeled photo set, record false acceptance and rejection, and revisit thresholds after model conversion. A faster wrong answer does not improve the upload journey.

Check the local feature before release

Use this checklist for the photo-quality flow:

• Capability detection covers every supported backend and an unsupported state.
• Model download, cache, compilation, cancellation, timeout, and memory failures have visible outcomes.
• The result gives an actionable message and never carries stale state between photos.
• Local, telemetry, remote fallback, and final-upload data paths are documented separately.
• Any remote transfer requires the notice and consent defined by the product contract.
• Representative devices pass measured startup, inference, memory, thermal, and quality thresholds.
• Visitors can use the declared fallback or cancel without losing unrelated work.

LiteRT.js makes local browser inference available to JavaScript applications, but dependable product behavior needs more than a successful demo. Detect, load, run, and fall back as explicit stages. Then support each claim with device, network, and quality evidence.