Production · 5 min · 11/14/2026

Unreal Engine Pixel Streaming Explained

How Unreal Engine Pixel Streaming works, what it needs to run, when it beats a download or a WebGL build, and where the real costs and risks sit.

What Pixel Streaming is

Pixel Streaming runs an Unreal Engine application on a machine with a GPU, usually in the cloud, and streams the rendered frames to a web browser as video. The user's clicks, key presses and touches travel back to the application, so the experience feels like a native app, but nothing is installed and the user's device does not need a powerful GPU.

It is part of Unreal Engine as a plugin, so a project that already runs as a packaged desktop build can usually be streamed without rewriting its content.

How it works

A Pixel Streaming setup has four moving parts:

The Unreal application with the Pixel Streaming plugin enabled. It renders each frame on the server GPU and encodes it as video.
A signalling and web server. It serves the web page the user opens and introduces the browser to the running application.
A WebRTC connection between the browser and the application. Video and audio flow to the user; mouse, keyboard, touch and custom messages flow back.
STUN and TURN servers that help the connection get through home and corporate firewalls.

For more than one user at a time, a matchmaker routes each new visitor to a free application instance. In practice that usually means one running application per active user, and each instance needs its own share of a GPU.

When it is the right choice

Pixel Streaming works well when:

The visuals need a high-end GPU, but your audience is on laptops, tablets or phones.
Users should not have to download or install anything, for example clients reviewing a building or a product.
You want the build and its assets to stay on your servers instead of on the user's machine.
Sessions are short and focused: a walkthrough, a configurator, a demo, a review.

It is a weaker fit when you expect thousands of people at the same moment on a small budget, when users are on poor mobile connections, or when a lighter WebGL build or a normal download would deliver the experience well enough.

Pixel Streaming vs a download or a WebGL build

Download (native app): the best quality and latency, and the user's GPU does the work, but people have to install it and you ship your assets to their machine.
WebGL / browser build: opens in a browser with no server GPUs, but the scene has to be simplified to run on the visitor's own hardware.
Pixel Streaming: full Unreal quality in a browser on almost any device, paid for with server GPUs per concurrent user and a dependency on network quality.

What drives the cost

Most of the running cost is GPU time. Three numbers decide it:

Concurrent users: how many people need a stream at the same moment, not how many visit in a month.
GPU class: how much GPU each session needs to hold your target frame rate and resolution.
Hours online: whether instances run all day or start on demand.

Infrastructure assumptions, not content, are where first milestones usually go over budget. We cover those in Pixel Streaming cost traps on the first milestone.

Getting the first milestone right

Lock the expected number of concurrent sessions and the GPU class before building the full scene.
Set an input latency budget and test it from the networks your real users are on, not only from the office.
Plan a fallback for when the stream drops or a session cannot start: a queue message, a video, or a lighter mode.
Profile the scene on the server GPU you will actually rent. Optimisation for streaming is the same frame-budget work as for any Unreal build.
Leave full branding of the stream page and multi-region failover until real users are on it.

Where we have used it

We have shipped Pixel Streaming projects in Unreal Engine 5, including an open-world city that streams to any browser and an architectural visualisation where clients walk interiors and swap finishes live.