October 28, 2026:


Opera has launched WebAI, a browser capability that lets websites and extensions run open-weight AI models directly on the user’s hardware — no cloud API calls, no vendor usage agreement, no separate application required. The feature ships today in early preview across Opera One, Opera GX, and Opera Neon, and it directly addresses the model-neutrality objection that blocked cross-browser consensus when Google shipped a similar API in Chrome five months ago. Before enabling it, readers should know that Opera’s majority owner, Kunlun Tech Co. Ltd., is a Beijing-based company that falls under China’s National Intelligence Law — a law that compels Chinese organizations to cooperate with government intelligence requests on demand.
The Chrome comparison is what makes today’s Opera WebAI announcement editorially significant for developers. In May 2026, Google shipped its Prompt API in Chrome 148 — also built on the W3C WebMachineLearning Working Group’s specification — but tied it exclusively to Google’s Gemini Nano model. That coupling required developers to accept Google’s Generative AI Prohibited Uses Policy to call a browser API, a first for the web platform that drew formal browser standards objections from Mozilla, Apple’s WebKit team, the W3C Technical Architecture Group, and Microsoft. Opera’s WebAI uses compatible open-weight models instead — meaning no single AI company controls which model the browser calls, and no usage policy governs web developer access to a browser API.
The decision of whether to enable WebAI is not straightforward, and this article provides the full framework a developer or user needs to make it.
The technical distinction that makes WebAI different from existing developer tools like WebLLM JavaScript inference library or Transformers.js is the layer at which it operates. WebLLM and Transformers.js are JavaScript libraries: the developer chooses a model, loads it alongside their extension, and manages inference themselves. WebAI is a browser-native API: the developer calls a standardized JavaScript method, the browser manages what model is loaded and how inference runs, and the developer’s code is agnostic to the underlying model. The full Opera WebAI developer documentation is available at next.opera.com.
The hardware layer underpinning this is WebGPU, the GPU access API for browsers that reached all major browser engines when Firefox 141 shipped it in July 2025. WebGPU enables GPU-accelerated matrix operations in the browser at speeds approaching native applications — the same operations that make LLM inference practical. Opera’s inference engine uses WebGPU where the user’s hardware supports it and falls back to CPU-based WebAssembly execution on devices without adequate GPU resources.
The open-weight model architecture is the engineering decision that differentiates Opera’s implementation from Chrome’s. Rather than embedding a fixed proprietary model — Chrome uses Gemini Nano — Opera’s WebAI downloads a compatible open-weight model when the user enables the feature. Open-weight models are models whose trained weight files are publicly distributed under permissive or custom licenses; no single vendor owns them or controls who can run them. The developer’s code calls a standardized API without knowing which specific model runs underneath: the browser’s abstraction layer handles the translation between API call and model inference pipeline. This is the model-neutrality that the W3C Technical Architecture Group had specifically requested in its formal objection to Chrome’s approach.
The browser-managed lifecycle is meaningful for end users. A single model download serves any number of extensions or web pages that call WebAI’s APIs, rather than each extension bundling its own model. Opera says the initial download takes a few minutes; the specific model size is not disclosed in current documentation, but is expected to be substantially smaller than the approximately 22 GB that Chrome’s Gemini Nano integration requires on some configurations.
Opera’s developer documentation exposes eight distinct APIs built on its WebAI inference engine. Three are highlighted as flagship capabilities for this launch.
The Prompt API handles text generation through stateful sessions: a developer sends a prompt, receives a response, and maintains context across an exchange without manually managing history. The W3C specification version supports streaming output and structured responses in addition to basic text. Developers who have built against cloud APIs like OpenAI’s Chat Completions endpoint will find the interface familiar — the difference is that the model runs in the user’s browser, not on a cloud provider’s GPU cluster.
The Decisions API is designed for classification tasks. Rather than prompting a model to generate free text, the developer presents content and a set of categories; the model returns a discrete judgment. Categorizing support tickets by urgency, tagging user feedback by sentiment, flagging potentially sensitive content for review — tasks that today require either cloud API calls or carefully tuned on-device classifiers — become single local calls.
The Semantic Embedder API converts text into vector representations suitable for semantic similarity comparisons. This is the primitive behind features like “find articles similar to this one” or “rank these results by relevance to my query.” Performing this computation locally means a user’s reading history and document collection need never be transmitted to a third party to power a semantic search feature.
The full suite also includes Summarizer, Writer, Rewriter, Translator, and Proofreader APIs — all drawing on the same W3C Writing Assistance APIs specification track that Google has been developing in parallel. The breadth of this implementation signals Opera is not cherry-picking the most convenient APIs but attempting comprehensive parity with the emerging standard’s full scope.
For independent developers and small teams, the economic argument is direct: AI-powered features that classify, summarize, or semantically search user content previously required either a cloud API subscription or the engineering cost of deploying and maintaining a local model server. WebAI eliminates both requirements. The tradeoff is performance variability: inference runs on the user’s own CPU and GPU — hardware that varies substantially across devices — rather than a purpose-built cloud cluster. Opera says it will continue making the inference engine lighter as the preview develops.
The model-neutrality question has been the central obstacle to cross-browser adoption of the Prompt API specification.
Chrome’s May 2026 implementation drew formal objections from four parties because it coupled a web-platform API — intended as a neutral building block usable by any browser — to a single vendor’s proprietary model and that vendor’s usage policy. Mozilla characterized it as a precedent that could compromise interoperability and platform neutrality. The W3C TAG design review cited “calcification risk”: a standard requiring one vendor’s model could entrench that vendor permanently in the web platform’s infrastructure.
Opera’s open-weight approach removes that specific objection. W3C WebMachineLearning Working Group meeting minutes from May 2026 show the group was already actively exploring model-neutral approaches — including Microsoft’s contributions toward an “OS-provided model” mechanism that avoids vendor lock-in. Opera’s implementation may not be a parallel track running alongside the standards process but an accelerant: a working implementation that demonstrates model-neutral local inference is feasible in a shipping browser, which answers the TAG’s objection with code rather than argument.
Whether Google, Mozilla, and Apple can now converge on a shared specification remains open. The next test will come when — or whether — the Prompt API and its companion specifications move from “experimental in Chromium-based browsers” to a standard all browser engines will implement.
Rather than releasing WebAI as a bare API, Opera shipped six working extensions simultaneously. All six are available on Opera’s add-on store today, as detailed in the Opera WebAI launch announcement.
Project Lens reads the current article and color-codes each paragraph by relevance to a project the user describes. High-relevance paragraphs stand out; the rest recede. It uses the Semantic Embedder API to compute proximity between article content and the user’s stated focus — a use case that requires no cloud call and processes no user data off-device.
Got It? generates a short comprehension quiz about the article just read. Questions are written on-device by the Prompt API. For students, educators, and self-directed learners who want something more than passive reading, this is precisely the kind of feature that cloud-API cost and data-privacy concerns had previously made impractical to build at scale.
Questionable Intelligence produces sarcastic commentary and charts about any article the user is viewing — demonstrating what a small, nimble on-device model can produce in the tone-register nearest entropy.
Semantic Art uses the Semantic Embedder API to render an article as a dynamic visual: sentences with similar meaning cluster together and drift apart in real time, turning text into a living map of its own semantic structure.
RecordIn Alchemy converts any article into the kind of breathlessly inspirational social-media post that fills certain professional networks. Opera describes the results as “insufferably inspirational” — a characterization that is both accurate and self-aware.
C·I·A·O (Cat Intelligence at Opera) generates an ASCII-art cat theater scene improvised around any topic the user provides. It demonstrates that a local model with no cloud round-trip can produce delightful nonsense quickly, and that performance constraints on early local inference are not a barrier to playfulness.
WebAI does not activate automatically on update. Users must navigate to Settings → Opera AI and toggle the Web AI API switch before anything is downloaded to their device. At that point, Opera downloads a compatible open-weight model — a process the company says takes a few minutes — and local inference becomes available to extensions and websites that request it. Users can disable WebAI at any time from the same settings screen.
Because the model runs on the user’s hardware, page content processed by WebAI’s APIs never reaches a cloud AI provider. For extensions that work with personal documents, reading history, or data users would prefer not to transmit to a third-party model service, this architecture is a meaningful structural guarantee — conditional on the broader Kunlun ownership context described in the next section.
Opera Limited is approximately 68% majority-owned by Kunlun Tech Co. Ltd., a company headquartered in Beijing and listed on the Shenzhen Stock Exchange. Kunlun’s controlling shareholder is James Yahui Zhou. This ownership structure is not in dispute, and it carries direct legal implications for Opera’s data obligations that every user should understand before enabling any Opera feature. Opera’s investor relations disclosures document this ownership structure.
China’s National Intelligence Law (2017), Article 7 states: “All organizations and citizens shall support, assist, and cooperate with national intelligence efforts in accordance with the law.” Article 14 grants intelligence institutions the right to request that relevant organizations provide “necessary support, assistance, and cooperation.” Obstruction of intelligence work carries administrative and potential criminal penalties under the law. These obligations apply to Chinese organizations regardless of where their products are deployed, where their servers are physically located, or what their stated privacy policies say. The full translated text is available at China Law Translate’s full law translation page.
China’s Data Security Law (2021) and Cybersecurity Law (2017) add data localization and government-access provisions that reinforce these intelligence-sharing obligations.
The precedent most relevant to US users: in 2019, the Committee on Foreign Investment in the United States (CFIUS) ordered Kunlun Tech to divest Grindr, the social networking app it had acquired, citing national security concerns about a Chinese company holding sensitive personal data — including location data, private messages, and HIV status — on US users. CNBC covered the Grindr divestiture as it unfolded. Kunlun sold Grindr in 2020. Opera was not subject to a similar CFIUS review at the time of its 2016 acquisition by the Kunlun-led consortium.
What WebAI specifically changes about this risk picture: Content processed by WebAI’s APIs is handled entirely on the user’s device. For the WebAI feature in isolation, local processing provides meaningful architectural mitigation — AI inference traffic does not transit Opera or Kunlun’s servers.
What WebAI does not change: Opera as a browser has access to browsing history, bookmarks, sync data, and traffic routed through its built-in VPN feature. These data streams remain subject to the same legal obligations that apply to Kunlun as a Chinese company. No independent third-party security audit of Opera’s browser or WebAI implementation was found during research for this article — an absence that is itself editorially significant.
Practical steps for readers with heightened privacy concerns: Run Opera in a dedicated browser profile with sync disabled; avoid using Opera’s built-in VPN for sensitive traffic; treat Opera as you would any browser from a company subject to a foreign government’s compelled data-access regime. No mitigation fully addresses the structural legal obligation described above. Readers who consider the Kunlun ownership disqualifying can use WebAI’s API surface as a reference implementation while waiting for equivalent functionality in browsers not subject to Chinese data law.
The early preview runs on Windows 64-bit systems with Intel or AMD processors and on Macs with Apple Silicon. The platform requirements are detailed in Opera’s developer documentation. It does not currently support Intel-based Macs, Linux, or Windows on Arm — a typical initial footprint for browser features that depend on hardware-accelerated inference paths, where engineering effort prioritizes the highest-volume hardware configurations first.
Opera’s history in local AI deployment offers context for how quickly platform coverage may expand. In April 2024, Opera became the first major browser to give users built-in access to local LLMs, initially supporting around 150 model variants from approximately 50 model families in its developer channel. By late 2024, that had grown to more than 2,000 variants from over 60 model families. The rapid expansion of that earlier program suggests Opera treats local AI infrastructure as a core investment rather than a peripheral feature.
The broader ecosystem is moving in the same direction. Google’s LiteRT.js browser inference engine, released in July 2026, brought native-speed on-device inference to the browser via JavaScript. WebLLM and Transformers.js, both updated in September 2026, enabled any developer to run models up to Llama-2 scale in a browser tab without browser-vendor involvement. What WebAI adds to this ecosystem is standardization: a browser-managed model lifecycle and a stable API surface that persists across browser updates and doesn’t require the developer to ship a model.
Whether WebAI’s APIs become a cross-browser standard depends on whether the W3C WebMachineLearning Working Group can reach consensus on the model-neutrality and governance questions that produced friction in May 2026.
The May 2026 group meeting minutes show movement on exactly those questions. Microsoft had contributed toward an “OS-provided model” approach that avoids coupling the API to a single vendor’s model — the same architectural principle Opera has implemented with open-weight models. Mozilla’s formal standards-position issue had moved into the Prompt API’s own repository, indicating the objection was being addressed inside the standardization process rather than left as external criticism. The group was actively exploring model-neutral implementation paths.
Opera’s working implementation provides the standardization process with something it has lacked: a concrete demonstration that model-neutral local inference via a Prompt API-compatible interface is feasible in a production browser. That shifts the conversation from “can this be done without coupling to Gemini Nano” to “here is one way it has been done.”
Opera WebAI is a technically substantial implementation of model-neutral browser AI that addresses the specific objection that blocked Chrome’s Prompt API from achieving cross-browser adoption. Developers who need AI features without cloud costs, data-transmission overhead, or vendor usage agreements have a working API to evaluate today. The decision to use it requires weighing that capability against a fixed legal condition: Opera’s majority owner is a Chinese company subject to China’s National Intelligence Law, which compels cooperation with intelligence requests regardless of where Opera’s servers are located or what its privacy policy says. Local AI processing mitigates one data-exposure vector; it does not alter Opera’s obligations as a product of a company under Chinese law. That tradeoff — a genuinely useful, model-neutral browser AI standard, from a browser whose owner cannot legally refuse a Chinese government data request — is the full picture.
Both are browser-native AI APIs built on the W3C WebMachineLearning Working Group’s Prompt API specification. The key difference is the underlying model and the legal conditions of use. Chrome’s implementation requires Google’s proprietary Gemini Nano and requires developers to accept Google’s Generative AI Prohibited Uses Policy — a vendor-specific usage agreement as a condition of calling a browser API, a first for the web platform. Opera’s WebAI runs compatible open-weight models — publicly available model weights not controlled by any single vendor — so developers face no vendor usage policy, and no single AI company controls which model the browser calls. Opera also supports models the user already has installed locally.
Content processed by WebAI’s APIs is handled entirely on your device — AI inference traffic does not transit Opera or Kunlun’s servers. However, Opera as a browser has access to browsing history, bookmarks, sync data, and traffic routed through its built-in VPN. Opera’s majority owner, Kunlun Tech Co. Ltd. (Beijing), falls under China’s National Intelligence Law, which compels Chinese companies to cooperate with government intelligence requests. The local-processing architecture of WebAI mitigates data exposure for that specific feature; it does not address Opera’s broader data obligations as a product of a Chinese-owned company.
Opera’s current documentation does not disclose the specific model name or family used in WebAI’s initial release. The feature uses compatible open-weight models managed by Opera’s inference engine. Opera’s prior local AI work — which began in April 2024 and grew to support more than 2,000 model variants by late 2024 — has included models from the Llama, Mistral, and Phi families, among many others, suggesting a broad range of compatible architectures. Opera’s on-device AI expansion history is documented in investor materials.
Not yet. The early preview supports Windows 64-bit (Intel and AMD processors) and Macs with Apple Silicon. Intel-based Macs, Linux, and Windows on Arm are not currently supported. Opera has said the inference engine will continue to be optimized during the preview period; platform coverage is expected to expand as the feature matures.