In Browser Kitty, two tools can both be fully local and still expose different features depending on the browser. A feature may work on desktop but not on a phone, or an acceleration path may be available on one device but not another even under the same browser brand.
That is not a contradiction. In this article, fully local processing means that the user data being processed is not sent to an external server and that its processing completes on the device. Feature availability is a separate question: which web APIs the environment implements, whether secure-context, permission, user-activation, and other conditions are satisfied, and what the operating system and hardware can actually provide.
Five layers that affect capabilities even when processing stays local
Where the data is processed
Does the app send files and inputs to an external server, or process them with on-device JavaScript, Wasm, and web APIs? This is the axis that determines whether processing is local.
Whether the Web API is implemented
Features such as Web NFC and WebGPU are not implemented across every major browser at the same time or to the same extent. If the API is absent, that feature cannot be used.
Whether secure-context, permission, and user-activation conditions are met
Camera access, screen capture, Web Share, Wake Lock, and similar features can depend on a secure context, permissions, user activation, Permissions Policy, or other conditions. API presence alone does not guarantee availability.
What the OS and hardware can provide
GPU adapters, NFC hardware, video codecs, and system voices are environment-dependent. Even when an API exists, the configurations and performance available through it can differ by device.
What the app does when a feature is missing
Acceleration and convenience features should not become accidental hard requirements. Browser Kitty enables them after capability checks and uses an alternate path when practical.
Fully local does not mean identical capabilities
Locality is about the data path, while feature availability is about API support, runtime conditions, and device capabilities. For example, image processing can remain entirely on-device with JavaScript or Wasm while optional features such as Web Share, WebGPU, or Web NFC are not available in every environment.
A browser is not one fixed runtime
Even when a web standard exists, browsers do not necessarily ship the same feature on the same day. Desktop and mobile editions, OS web views, and older releases can also differ in timing or conditions. MDN Baseline is a useful summary of support in major browsers, but it is not a guarantee for older devices, web views, performance, or permissions.
As of September 2026, MDN marks WebAssembly and getUserMedia() as widely available. Web NFC, WebGPU, Web Share, and WebCodecs VideoEncoder are still marked as having limited availability. Screen Wake Lock reached Baseline 2025, while older devices and browsers may still lack it.
| Feature | MDN status (Sep 2026) | What to check in an app |
|---|---|---|
| WebAssembly | Widely available | Check memory, workers, CSP, and performance in addition to Wasm support itself |
| getUserMedia() | Widely available | Check secure context, camera/microphone permission, and actual input devices |
| Screen Wake Lock | Baseline 2025 | Check older environments, document visibility, and device/user policy |
| Web Share | Limited availability | Check OS share integration, shareable payload types, and user-gesture requirements |
| WebCodecs VideoEncoder | Limited availability | Check both API presence and support for the codec configuration you actually need |
| WebGPU | Limited availability | Check API presence, GPUAdapter availability, features/limits, and device performance |
| Web NFC | Limited availability / Experimental | Check browser support, NFC hardware, NDEF-compatible tags, and runtime conditions |
An API can exist while the configuration you need is unavailable
Video processing makes this distinction easy to see. Even when WebCodecs VideoEncoder exists, the codec, resolution, frame rate, or hardware-acceleration combination you need may not be supported on that device. WebCodecs therefore provides isConfigSupported() so an app can test its actual configuration before choosing a path.
WebGPU is similar. navigator.gpu may exist while requestAdapter() still returns no suitable GPUAdapter, and adapters expose different features and limits. Checking only for the API name is not enough; an app needs to check the capability it actually requires on the current device.
Requiring a secure context does not make processing cloud-based
Powerful features such as camera and microphone access, screen capture, WebGPU, Web Share, and Screen Wake Lock may require a secure context such as HTTPS. This is a web security condition for exposing powerful APIs in a trustworthy context; it does not mean that user data is processed on a server.
For example, an HTTPS-delivered page can obtain camera input through getUserMedia() and process it locally with Canvas or Wasm. Localhost and file:// can also be treated as potentially trustworthy in some contexts, but API-specific conditions and browser behavior still differ. Browser Kitty therefore tests standalone execution separately from each API's requirements.
Three differences Browser Kitty has encountered in real tools
Browser Kitty handles browser differences feature by feature rather than relying only on a browser-name support list. Separating core functionality from acceleration and OS integration prevents one missing API from unnecessarily making an entire tool unusable.
| Tool | Capability that varies | How the tool handles it |
|---|---|---|
| Presentation Video Maker | WebCodecs / system-speech capture path | Uses the accelerated WebCodecs path when available and falls back to MediaRecorder + FFmpeg Wasm. On phones, narration uses microphone recording or local audio files instead of TTS capture |
| Wi-Fi Share | Web Share / Screen Wake Lock / Web NFC | Keeps QR generation and copy as core features, treats OS share and Wake Lock as enhancements, and exposes NFC tag writing only as an experimental feature on supported environments |
| Smart Image Sorter | Image decoding and device capacity | Embeds the AI model and runtime for local inference, while image-format decoding support and the headroom for many high-resolution images still vary by browser, OS, and device |
Fallbacks are how core functionality survives capability differences
A robust way to handle browser differences is to make the core workflow work first, then layer acceleration or convenience features on top only where they are available. This is close to progressive enhancement rather than requiring every environment to support the same advanced API.
Browser Kitty checks more than the existence of an API name when necessary: the desired WebCodecs configuration, a usable WebGPU adapter, a shareable Web Share payload, and so on. If a capability is missing, the app may choose an alternate path, hide the unavailable action, or label it experimental depending on the feature.
Check capabilities in the current environment, not just a browser name
Browser-name labels such as “Chrome supported” or “Safari unsupported” are easy to read but often too coarse because results can also vary by version, OS, device, GPU, codec support, and permissions. Browser Kitty therefore prefers checking the APIs and capabilities actually needed in the current environment and, when unavailable, explaining that the feature cannot be used there or offering an alternate path.
Five principles Browser Kitty uses for browser differences
To absorb differences across desktop, mobile, and browsers without changing the local-processing model, Browser Kitty generally follows these principles.
- Detect the featureCheck navigator and the target API directly instead of deciding availability from the browser name alone.
- Check the required capabilityFor capabilities where API presence is insufficient, verify the actual requirement—for example, the WebCodecs codec configuration or a usable WebGPU adapter.
- Make the core workflow work firstBuild the core user goal first using broadly available mechanisms such as QR generation, file APIs, or Wasm where appropriate.
- Provide a fallbackWhen an acceleration or OS-integration feature is unavailable, switch to another path, hide the action, or label it experimental instead of letting the whole app fail.
- Test real desktop and mobile environmentsTest real workflows on both desktop and mobile, including permissions, screen size, memory, secure-context requirements, and OS integration.
Presentation Video Maker
Turn PowerPoint (PPTX) slides into narrated MP4 videos locally using speaker notes, recordings, or local audio files.
Tips and limitations
- 'The API exists' and 'the API supports the configuration I need' are different claims. Video codecs and GPU features often need a capability check after feature detection.
- A secure-context requirement is not evidence of cloud processing. HTTPS and other trustworthy contexts are conditions for safely exposing powerful APIs, while processing location is a separate axis.
- Support changes over time. Runtime feature detection plus real-device testing ages better than permanently hard-coding browser names into behavior or documentation.
Frequently asked questions
Is it contradictory for a fully local tool to have a feature unavailable in Safari?
No. Fully local processing describes where user data is processed. Browser API support is a separate question; if the browser does not implement a required API, that feature can be unavailable while the rest of the tool remains local.
If a feature requires a secure context, does that mean it is processed on a server?
No. A secure context is a condition for exposing powerful web APIs in a trustworthy environment. HTTPS is the usual case, while localhost and file:// may also be treated as trustworthy in some contexts. In any of these cases, camera input, files, video, or AI inference can still be processed entirely on the device.
If WebAssembly is widely available, do FFmpeg and AI run the same way in every browser?
Not necessarily. Wasm support does not erase differences in available memory, workers, SIMD/threading conditions, media input/output, or device performance. For heavy workloads, 'it can start' and 'it runs at a practical speed and size' are separate questions.
Is checking for WebCodecs presence enough?
Not always. APIs such as VideoEncoder.isConfigSupported() let an app verify the codec configuration it actually wants to use on the current device. Browser Kitty follows the same capability-first approach before choosing accelerated paths.
Why prefer feature detection over browser-name checks?
Because capabilities can differ by browser version, OS, device, web view, GPU/codec support, and permissions even under the same browser name. Checking the capability you actually need is also more resilient to future browser updates.
Does opening a single HTML file offline guarantee every feature works exactly like the hosted version?
No. Many JavaScript and Wasm workflows can be self-contained, but APIs with secure-context, origin, permission, or OS-integration requirements can behave differently depending on how the file is opened. Browser Kitty tests standalone execution and API-specific conditions separately.
References
Browser support changes over time, so this article uses MDN Baseline and official API documentation as of September 2026. Browser Kitty implementation examples can be inspected in the public repositories below.
- MDN Web Docs Baseline compatibility
- MDN Web Docs Secure contexts
- MDN Web Docs WebAssembly
- MDN Web Docs VideoEncoder
- MDN Web Docs WebCodecs codec selection
- MDN Web Docs WebGPU API
- MDN Web Docs Web Share API
- MDN Web Docs Web NFC API
- MDN Web Docs Screen Wake Lock API
- GitHub / ttomohisa Presentation Video Maker
- GitHub / ttomohisa Wi-Fi Share
- GitHub / ttomohisa Smart Image Sorter