> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streampixel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Unreal in the browser vs pixel streaming

> Unreal Engine 5.9 adds a web (WebAssembly + WebGPU) platform. What it can and cannot do, and when a streamed project is the right call.

Unreal Engine 5.9 ships a **web platform**: a project is compiled to WebAssembly and rendered through WebGPU, so it runs inside the viewer's browser on the viewer's own CPU, GPU and memory. No server is involved — the files sit on a static host and the browser downloads and runs them, the way an installed `.exe` would.

**Pixel streaming** is the opposite arrangement: the project runs on a GPU server and the viewer receives a video stream and sends input back. The browser only has to play a video.

Both put an Unreal project behind a link. They solve different problems. This page is the honest comparison, based on Epic's own 5.9 documentation and what our customers' viewers actually use.

## Side by side

| | Unreal web platform (5.9) | Pixel streaming (Streampixel) |
| - | - | - |
| Where the project runs | the viewer's machine | a datacenter GPU |
| What the viewer needs | a current Chrome or Edge on Windows with WebGPU; a capable GPU | anything that plays video |
| Browsers (Epic's 5.9 support matrix) | Chrome/Edge on Windows supported; Chrome on Linux with flags; Chrome on macOS not verified; Firefox slower, reduced renderer; **Safari on macOS and iOS not supported** | every current browser, including Safari and iOS |
| Phones and tablets | warned off by default; **no touch input** | supported, touch included |
| Before the first frame | the whole build is downloaded on the first visit (cached after) | 5–10 seconds, no download |
| Build size that works | hundreds of MB; multi-GB builds mean minutes of waiting | the same build you package for Windows, whatever its size |
| Memory | one browser heap, 4 GB by default | the server's RAM and VRAM |
| Renderer | two tiers chosen per viewer by a GPU check: a forward renderer for most machines, a deferred renderer for fast discrete GPUs. **No Nanite, no ray tracing; Lumen off; hair off** | whatever the project uses — Lumen, Nanite, ray tracing, hair |
| Same picture for everyone | no — depends on the viewer's GPU and browser | yes — same GPU every time |
| Your assets | downloaded to every viewer's disk | never leave the server |
| Access control | static files; gating is the host's problem | password, SSO, allowed domains, per-session tickets |
| Updates | every viewer re-downloads what changed | swap the build; viewers never notice |
| Analytics | none built in | sessions, concurrency, duration, device mix, per-session logs |
| Multiplayer, voice, plugins | browsers have no UDP; each plugin must be ported to WebAssembly | runs as on Windows |
| Cost model | hosting is close to free; the viewer's hardware does the work | per concurrent viewer |
| Build pipeline | Unreal source build on Windows, a fixed emscripten toolchain, a long, memory-hungry link | package for Windows, upload |

## Which one fits

**The web platform is a good fit when all of these are true**

* the project is small — a few hundred MB packaged — and lit without Lumen
* the audience is on desktop Chrome or Edge, and losing phone, iPad, Mac/Safari viewers is acceptable
* a different look on different machines is acceptable
* the content can be public — anyone can keep the downloaded files
* you build the engine from source and can maintain a separate web pipeline

**Stream the project when any of these is true**

* viewers are on phones, tablets, Macs or in Safari (for a typical product configurator, roughly a third of viewers are on a phone)
* the project uses Lumen, Nanite, ray tracing or is more than about a gigabyte
* the first frame has to appear in seconds, from a link in an email or a QR code
* the picture has to be the same for every viewer — a brand experience, a client review, a configurator
* the assets are confidential or unreleased
* you need sign-in, allowed domains, session analytics or a webhook when a build is ready
* the project is multiplayer, uses voice, or depends on plugins that are not ported to WebAssembly

## Can a project do both?

Not from one build today. The web platform is a separate cook, and the Pixel Streaming plugins do not build for WebAssembly, so a project that wants a web build **and** a stream maintains two packages. If you are weighing that, [talk to us](mailto:support@streampixel.io) — the useful combination is one link that serves whichever the viewer's device can run.

## Where this comes from

The web-platform facts above are from Epic's 5.9 documentation (`Engine/Platforms/Wasm/Docs` in the engine source: the support matrix, performance and shipping pages). 5.9 is the platform's first release and Epic marks it experimental; browser support and renderer features will change with later versions. We will keep this page current.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.