WebLLM - Browser-Native AI Protocol

Every major operating system is shipping AI APIs. Apple has Core ML and Apple Intelligence. Android has ML Kit and on-device Gemini. Windows has Windows ML and Copilot runtime.

The browser—the world's most universal application platform—has nothing.

This gap won't last. The question isn't whether browsers will get AI capabilities, but what they'll look like, who will design them, and whether the result will serve users or lock them into vendor ecosystems.

This is the case for navigator.llm: a standards-based, permission-gated, user-controlled AI API for the web platform.

The State of AI in Web Apps Today

How Developers Add AI Now

Server-side integration (most common):

// Developer's server calls AI APIs
const response = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify({ message: userInput }),
});

This works, but:

Requires server infrastructure
Developer pays API costs
User data leaves their device
Developer chooses the AI provider (not user)
Latency for every request

Client-side ML libraries:

import { pipeline } from '@xenova/transformers';
const classifier = await pipeline('sentiment-analysis');

This works for some cases, but:

Large model downloads (100MB+)
Complex setup
Limited to supported models
No user choice in providers
Different API for each library

Native apps:

Platform fragmentation
Installation friction
Not the web

The Result: Fragmentation

Every AI-powered web app reinvents:

Provider integration
API key management
Error handling
Fallback logic
Privacy policies

Users deal with:

Different AI per app
Inconsistent privacy practices
No control over providers
Per-app subscriptions or usage limits

What a Browser AI API Enables

Imagine if AI worked like geolocation:

// Geolocation: user grants permission, browser provides capability
navigator.geolocation.getCurrentPosition(callback);

// AI: same pattern
const response = await navigator.llm.prompt('Summarize this page');

For Developers

Simplicity:

// Before: Server setup, API keys, provider SDKs, error handling...

// After:
const result = await navigator.llm.prompt(input);

Provider agnosticism:

Write once, works with any AI
No API key management in code
No provider-specific SDKs
Users bring their own AI

Reduced costs:

No server infrastructure for AI calls
No API costs (user pays their provider)
No usage tracking/billing systems

For Users

Control:

Choose their AI provider (OpenAI, Anthropic, local, etc.)
Use local AI for privacy
Configure once, works on all sites
Revoke access per-site

Privacy:

Local AI option (data never leaves device)
Know which sites access AI
Trust the browser's permission model

Consistency:

Same AI across all web apps
Single subscription covers all sites
Familiar permission UX

For the Web Platform

Standardization:

One API instead of dozens of libraries
Interoperable across browsers
Stable, documented behavior

Security:

Browser-mediated access
Permission model prevents abuse
No rogue API key exposure

Evolution:

Ships as browsers evolve
Backward compatible
Room for enhancement

The Design: Learning from navigator.*

The best browser APIs share patterns. navigator.llm should follow them.

Lesson from Geolocation: Permission-Gated Access

// Geolocation asks permission once, remembers per-site
navigator.geolocation.getCurrentPosition(success, error);

// AI should do the same
const result = await navigator.llm.prompt(input);
// First call triggers: "example.com wants to use AI. Allow?"

Why it works:

Users understand the model (camera, mic work the same)
One decision covers ongoing use
Revocable via browser settings
Site can't silently use AI

Lesson from MediaDevices: Capability Selection

// Users choose which camera/mic
const stream = await navigator.mediaDevices.getUserMedia({
  video: { deviceId: preferredCamera },
});

// Users should choose which AI
// Browser handles this in settings, not per-request

Why it matters:

User might have multiple AI sources (local + cloud)
Preference might vary by use case
Browser centralizes this choice

Lesson from Service Workers: Progressive Enhancement

// Service Workers enhance, don't require
if ('serviceWorker' in navigator) {
  // Enable offline
} else {
  // Works anyway
}

// AI should enhance, not gate
if ('llm' in navigator) {
  // Use AI
} else {
  // App still works
}

Why it matters:

Not all users will have AI configured
Apps shouldn't require AI to function
Graceful degradation is expected

Lesson from Notifications: Don't Get Abused

Notifications taught us what happens when sites spam permission prompts:

Users auto-deny everything
Trust erodes ecosystem-wide
Browsers add restrictions

For AI, we must:

Design for appropriate prompting (on user action, not page load)
Make value clear before asking
Avoid patterns that train users to deny

API Shape: A Proposal

Based on web platform patterns, here's what navigator.llm could look like:

Basic Prompt

// Simple completion
const response = await navigator.llm.prompt('What is the capital of France?');
// Returns: "The capital of France is Paris."

Streaming

// Real-time response display
const stream = navigator.llm.streamPrompt('Write a haiku about coding');

for await (const chunk of stream) {
  outputElement.textContent += chunk;
}

Sessions (Context)

// Maintain conversation context
const session = await navigator.llm.createSession({
  system: 'You are a helpful assistant.',
});

const response1 = await session.prompt('My name is Alice.');
const response2 = await session.prompt("What's my name?");
// Remembers: "Your name is Alice."

session.close();

Permission Management

// Query permission state
const status = await navigator.permissions.query({ name: 'llm' });
// status.state: 'granted', 'denied', or 'prompt'

// Watch for changes
status.addEventListener('change', () => {
  console.log('AI permission changed:', status.state);
});

Capability Detection

// Feature detection
if ('llm' in navigator) {
  // WebLLM or native support available
}

// Capability query (future)
const capabilities = await navigator.llm.getCapabilities();
// { streaming: true, maxTokens: 4096, ... }

Error Handling

try {
  const result = await navigator.llm.prompt(input);
} catch (error) {
  switch (error.name) {
    case 'NotAllowedError':
      // Permission denied
      break;
    case 'NotSupportedError':
      // No provider configured
      break;
    case 'QuotaExceededError':
      // Rate limited
      break;
    case 'NetworkError':
      // Provider unavailable
      break;
  }
}

Why Browser Vendors Should Care

For Google (Chrome)

Google is already all-in on AI (Gemini, Bard, etc.). A browser AI API would:

Make Gemini the default AI for Chrome users
Reduce Android/Chrome capability gap
Drive Gemini adoption through seamless web integration
Compete with Apple's on-device AI narrative

For Apple (Safari)

Apple is pushing on-device AI (Apple Intelligence). A browser AI API would:

Extend Apple Silicon advantage to web
Privacy story: "AI stays on your Mac/iPhone"
Differentiate Safari with local AI performance
Control AI access on Apple platforms

For Mozilla (Firefox)

Mozilla cares about user agency. A browser AI API would:

User chooses provider (not developer, not browser vendor)
Privacy-preserving local options
Open standard, not proprietary lock-in
Aligns with Mozilla's mission

The Competitive Pressure

iOS 18 has on-device AI
Android has Gemini integration
Windows has Copilot everywhere
macOS has Apple Intelligence

If the web doesn't get AI capabilities, developers will build native apps instead. The web loses relevance.

The Privacy Argument

AI raises legitimate privacy concerns. A browser AI API actually improves the situation:

Current State (Bad)

┌───────────────────────────────────────────────┐
│ User types sensitive query                    │
│              ↓                                │
│ Web app sends to its server                   │
│              ↓                                │
│ Developer's server sends to OpenAI/Anthropic │
│              ↓                                │
│ AI provider processes (logs? trains? sells?) │
└───────────────────────────────────────────────┘

Users don't control:

Which AI processes their data
Whether data is logged
Whether data trains models
Who has access

With Browser AI API (Better)

┌─────────────────────────────────────────────────┐
│ User types sensitive query                      │
│              ↓                                  │
│ Browser routes to USER'S chosen provider        │
│   - Option A: Local (Ollama) → Data stays home │
│   - Option B: Cloud (OpenAI) → User's account  │
│   - Option C: On-device → Never leaves browser │
└─────────────────────────────────────────────────┘

Users control:

Which AI processes their data
Whether to use local or cloud
Their relationship with the AI provider
Per-site permissions

The browser becomes a privacy guardian, not just a pipe to random servers.

The Developer Burden Argument

Every AI feature today requires developers to:

Choose a provider (and lock users in)
Set up server infrastructure (or expose API keys)
Manage API keys (rotation, rate limits)
Handle billing (usage tracking, limits)
Write provider integration (SDK, error handling)
Implement fallbacks (what if API is down?)
Write privacy policies (data handling disclosures)
Get legal review (AI-specific terms)

With navigator.llm:

Call the API
Done

The browser handles provider selection, permissions, error handling, and privacy. Developers write features, not infrastructure.

The Standards Process

How would navigator.llm become real?

Phase 1: Proof of Concept (Now)

Extensions like WebLLM demonstrate the API
Developers build with it
Patterns solidify
Edge cases discovered

Phase 2: Browser Experimentation (Next)

Chrome Origin Trial
Safari Technology Preview
Firefox Nightly experiments
Multiple implementations test interop

Phase 3: Standards Work (Following)

W3C/WHATWG proposal
Multi-stakeholder input
Privacy/security review
Formal specification

Phase 4: Stable Shipping (Eventually)

Chrome stable
Safari stable
Firefox stable
Universal availability

Timeline estimate: 2-4 years from serious browser interest to universal support (based on WebGPU timeline).

Counterarguments Addressed

"AI is too complex for a simple API"

Geolocation is complex (GPS, cell towers, WiFi positioning, privacy). The API is simple:

navigator.geolocation.getCurrentPosition(callback);

AI can be the same:

navigator.llm.prompt(input);

Complexity lives in the implementation, not the interface.

"Models change too fast for standardization"

The API abstracts over models. navigator.llm.prompt() doesn't specify GPT-4 vs Claude vs Llama—it requests a capability. The browser/user chooses the implementation.

This is like getUserMedia() not specifying camera hardware.

"What about model selection, parameters, etc.?"

Start simple:

navigator.llm.prompt('Hello');

Expand over time:

navigator.llm.prompt('Hello', {
  temperature: 0.7,
  maxTokens: 1000,
  preferLocal: true,
});

Web APIs routinely add options in later versions.

"What about image generation, embeddings, etc.?"

Start with text (the common case). Add capabilities as patterns emerge:

// Future
navigator.llm.generateImage(prompt);
navigator.llm.embed(text);
navigator.llm.transcribe(audio);

Each could be separate API surface or unified under navigator.ai.

"Companies won't agree on a standard"

They agreed on:

Geolocation
WebRTC
WebGPU
Service Workers

When user benefit is clear and no single company can dominate, standards emerge.

The Ask

For browser vendors:

Start experimenting
Join the conversation
Don't let AI become a native-app-only feature

For standards bodies:

Open a discussion
Learn from WebGPU's success
Involve privacy advocates early

For developers:

Build with polyfills (like WebLLM)
Demonstrate demand
Provide feedback on API design

For users:

Expect AI to be user-controlled
Support browsers that prioritize your agency
Try WebLLM, provide feedback

Conclusion

The web has always grown by absorbing capabilities that seemed impossible:

2009: "Real-time location in browser? Impossible." → navigator.geolocation
2012: "Video calls in browser? Impossible." → WebRTC
2017: "Native performance in browser? Impossible." → WebAssembly
2023: "GPU compute in browser? Impossible." → WebGPU

Now: "AI in browser? Impossible." → navigator.llm

The pattern is clear. The need is clear. The design patterns exist.

navigator.llm isn't a fantasy—it's an inevitability. The question is whether we get there through thoughtful design that prioritizes users, or through fragmented vendor implementations that prioritize lock-in.

WebLLM is building the prototype. Browser vendors will write the final spec. The web platform will grow again.

The future of AI in the browser is being decided now. Let's make sure it's the right one.

The Case for navigator.llm