Pico WebXR in 2026: What the Developer Portal Actually Offers

If you arrive at Pico's developer portal looking for WebXR documentation, the first thing you hit is /document/web/ — a page that serves a logo and nothing else. No tutorials, no API reference, no sample code. It is a placeholder, and it has been a placeholder long enough that you have to wonder whether the web platform is a first-class citizen in Pico's strategy or an afterthought.

The answer, as of July 2026, is mixed. Pico ships a capable Chromium-based browser that supports WebXR. The native SDKs (Unity, Unreal, OpenXR) are mature. But the documentation gap between "I want to serve a WebXR page to a Pico headset" and the actual runtime behaviour is wide enough that you will spend an afternoon hunting through GitHub repos, old forum posts, and the PICO Browser APK changelog to piece together what works. This article is that afternoon, condensed.

What Works for Web

The table below maps the four surfaces you can target and what each gives you.

Surface	Target	What You Get	When to Use	GitHub / Link
WebXR via PICO Browser	Vanilla web content served over HTTPS	Immersive-vr and immersive-ar sessions, Gamepad API (Pico controllers), full Chromium DevTools remote debugging	You want to serve XR content from a standard web server with zero app-store friction	picoxr.com/document/web/ (placeholder)
OpenXR via native C/C++ SDK	Native executables sideloaded or distributed via PICO Store	Raw OpenXR 1.1 runtime access, custom rendering pipelines, no overhead between your code and the compositor	You need frame-level control, custom swapchains, or low-level graphics interop (Vulkan/D3D12)	github.com/picoxr/support
Unity / Unreal native SDK	Full platform-integrated apps	Accounts, social, achievements, leaderboards, IAP, DLC, subscriptions, cloud storage, hand tracking	You are building a polished app or game that needs the full PICO platform services layer	picoxr.com/document/native/unity/
Legacy Android Helper JAR	Android-level integration for Unity/Unreal	Launch PICO Browser at a given URL, control device settings, system-level intent dispatch	You are writing a native app that needs to launch WebXR content in the browser	Bundled with older SDK releases

The Four SDK Surfaces

1. PICO Browser (WebXR)

PICO Browser is a Chromium fork that ships on every Pico headset. It implements the WebXR Device API for both immersive-vr and immersive-ar modes, which means any standard Three.js, A-Frame, or raw WebXR page will work — provided it is served over HTTPS and the user grants the session prompt. Controllers surface through the standard Gamepad API with the Pico mapping.

There is no standalone "WebXR Viewer" app. If you want users to reach your WebXR content, you either send them a link, embed it in a launcher app, or set it as the browser home page. Debugging works via Chrome DevTools over USB/ADB — the browser exposes the standard remote debugging protocol.

What is missing: any first-party WebXR sample, any documentation for Pico-specific WebXR extensions (if they exist), and any word on WebGPU for XR. The browser supports WebGPU for flat content, but WebGPU in immersive sessions is not documented.

2. Native OpenXR SDK

The OpenXR SDK lives at github.com/picoxr/support and ships several demo projects:

• OpenXR_Demos — C/C++ samples showing controller interaction, passthrough, and basic rendering
• OpenXR_VideoPlayer_Demo — 360° and spatial video playback
• PICO_UE5_OpenXRSample — Unreal Engine 5.4 wrapper demonstrating the Pico OpenXR runtime

This is the path for developers who need frame-level control. Pico's OpenXR runtime supports the core OpenXR 1.1 spec plus extensions for passthrough, hand tracking, and body tracking. The demo code is functional but lightly commented; expect to read the OpenXR spec alongside it.

3. Unity Integration SDK

The Unity SDK is the most complete surface. It wraps the full PICO platform services stack:

• Accounts and authentication
• Social features (friends, rooms, matchmaking)
• Achievements and leaderboards
• IAP, DLC, and subscriptions
• Cloud save
• Hand tracking, body tracking, eye tracking
• Controller and haptic feedback

If your app needs any of these services, Unity is the path of least resistance. The SDK documentation is adequate — not stellar, but sufficient to ship. The same services are available in Unreal through a parallel SDK.

4. PICO Motion Tracker and Body Tracking

The PICO Motion Tracker (a 3DoF leg tracker that pairs with PICO 4 series) is supported at the OpenXR and Unity/Unreal SDK levels. For WebXR, there is no body tracking extension exposed to JavaScript — you get headset and controller poses only. If body tracking is a requirement, you must go native.

5. LauncherWebVR Demo

One particularly useful sample in the OpenXR demos is LauncherWebVR. It shows how a native app can launch PICO Browser at a specific URL, effectively bridging native and web content. This is the recommended pattern if you need platform services (native) and WebXR content (browser) in the same user flow: build a thin native launcher that opens the browser to your WebXR app.

Documentation Gaps

Let me be direct about what is missing or broken:

• /document/web/ is a dead end. The portal navigation promises WebXR documentation but delivers a placeholder. You will find more useful information in PICO Browser's release notes than on the developer site.
• No WebXR extension reference. If PICO Browser exposes any vendor-specific extensions (for foveation, passthrough, or performance hints), they are not documented anywhere official.
• WebXR + platform services is impossible. There is no JavaScript SDK for PICO platform services. If you need accounts, IAP, or achievements, you must write a native app (Unity/Unreal/OpenXR) and cannot serve it as a web page.
• Sample code is sparse. The OpenXR demos compile and run but are minimal. Expect to triangulate between the OpenXR 1.1 spec, the Khronos registry, and the Pico source.
• The Android Helper JAR is legacy. It exists in older SDK tarballs but has no active documentation or support pathway. Use it only if you are maintaining an older project.

Which Path for Which Developer

You serve static WebXR content (a gallery, a visualisation, a simple game) and do not need platform services: PICO Browser WebXR is your path. Write standard WebXR code, serve over HTTPS, send users a link. This is the lowest-friction path and works today.

You need frame-level control or custom graphics pipelines: Native OpenXR SDK. Be prepared to read the OpenXR spec and write C/C++. The demo code will get you started but will not hold your hand.

You are building a game or app that needs accounts, social features, or IAP: Unity or Unreal SDK. This is where Pico invests its documentation effort. The trade-off is that you are locked into the engine's XR integration path and cannot serve content over the web.

You want to combine native platform services with WebXR content: Build a native launcher that uses the LauncherWebVR pattern. Launch PICO Browser at your WebXR URL from a thin native shell. It is more moving parts than ideal, but it works.

If you are new to WebXR on Pico, start with your browser, a local HTTPS server, and a WebXR sample page. Once you have that working, you will have a clear picture of what the platform gives you — and what it does not. For a general introduction to WebXR fundamentals that apply across all headsets, see the standard WebXR overview.