Unreal Engine for the Web: Pixel Streaming and Beyond

What Is Unreal Engine Pixel Streaming

Unreal Engine is a AAA game engine built by Epic Games, known for photorealistic rendering, massive open worlds, and titles like Fortnite and the Final Fantasy VII Remake. It was never designed to run inside a web browser the way HTML5 game engines like Phaser or Three.js do. The engine depends on native GPU APIs (DirectX 12, Vulkan, Metal) and compiles to native machine code, making a direct browser port impractical with current web standards.

Pixel streaming solves this problem by moving the rendering entirely off the user's device. Your Unreal Engine application runs on a cloud server equipped with a dedicated GPU, typically an NVIDIA card with hardware video encoding support. The application renders frames at full fidelity, exactly as it would on a high-end gaming PC. The Pixel Streaming plugin captures those frames directly from the GPU frame buffer, encodes them as compressed H.264 or H.265 video using the GPU's hardware encoder, and transmits the resulting video stream to a web browser over WebRTC.

The browser displays this video stream in a standard HTML video element and captures user input, including keyboard presses, mouse movements, clicks, touch gestures, and gamepad input. That input travels back to the server over a WebRTC data channel, where the Unreal application processes it and renders the next frame accordingly. The result is a fully interactive experience that looks and feels like a native application but requires nothing more than a browser and an internet connection.

The concept is not new. Cloud gaming services like GeForce NOW and Xbox Cloud Gaming use the same fundamental approach. What makes Unreal Engine's pixel streaming distinctive is that it is built directly into the engine as a first-party plugin, giving developers full control over the streaming pipeline, the frontend client, and the server-side rendering configuration without depending on a third-party cloud gaming platform.

How Pixel Streaming Works Under the Hood

The pixel streaming architecture consists of four components that work together to create the interactive streaming experience. Understanding each component helps when configuring, debugging, and optimizing a deployment.

The Unreal Engine Application runs on a server with a dedicated NVIDIA GPU. It renders frames at the configured resolution and frame rate using the same rendering pipeline it would use on a local machine, including Nanite virtualized geometry, Lumen global illumination, ray tracing, Niagara particle effects, and all other engine features. The Pixel Streaming plugin hooks into the rendering pipeline to capture completed frames before they would normally be sent to a display output.

The Video Encoder is the GPU's hardware encoding unit, accessed through NVIDIA's NVENC API. NVENC can encode 1080p H.264 video at 60 frames per second with less than 2 milliseconds of encoding latency, which is critical for maintaining low total round-trip latency. The encoder supports both H.264 (widely compatible) and H.265/HEVC (better compression at equivalent quality), though browser support for H.265 via WebRTC is still limited in some environments. Audio from the Unreal application is captured separately and encoded alongside the video stream using the Opus codec.

The Signaling Server is a lightweight application, typically written in Node.js, that handles the WebRTC connection negotiation between the browser and the Unreal application. When a user opens the streaming URL, their browser contacts the signaling server and exchanges SDP (Session Description Protocol) messages to establish the connection parameters, including codec preferences, resolution, and network traversal information. The signaling server also manages ICE (Interactive Connectivity Establishment) candidate exchange, which allows the browser and server to find the best network path between them, including traversal through NATs and firewalls. Epic Games provides a reference signaling server implementation with the engine source.

The Frontend Client is a web page served to the user's browser. It contains an HTML video element that displays the incoming WebRTC video stream, and JavaScript code that captures input events (mouse, keyboard, touch, gamepad) and sends them to the Unreal application through the WebRTC data channel. Epic provides a reference frontend with the Pixel Streaming Infrastructure plugin, but production deployments almost always customize it to match the application's branding, add custom UI overlays, implement responsive design for mobile devices, and handle connection management gracefully.

The complete round trip works like this: the user moves their mouse in the browser, the frontend JavaScript captures the mouse event and sends it over the WebRTC data channel to the server, the Unreal application receives the input and processes it on the next tick, the new frame is rendered reflecting the input, NVENC encodes the frame, and the encoded frame travels back to the browser over WebRTC where it is decoded and displayed. In a well-optimized deployment with the server located near the user, this entire loop completes in 50 to 100 milliseconds.

Real-World Use Cases

Pixel streaming has found strong adoption in several industries where high visual fidelity matters more than unlimited concurrent users.

Architectural visualization firms use pixel streaming to let clients explore building designs interactively in their browser. The alternative, asking clients to install an application or visit a physical demo station, creates friction that pixel streaming eliminates. A single GPU server can host multiple architectural walkthroughs simultaneously, and the photorealistic rendering that Unreal Engine provides (complete with accurate lighting, reflections, and materials) gives clients a realistic impression of the finished space.

Automotive configurators allow customers to customize vehicles in real time, changing paint colors, wheel styles, interior materials, and trim packages while seeing photorealistic results. Major automotive manufacturers have adopted this approach because WebGL-based configurators cannot match the material fidelity that Unreal Engine achieves with ray-traced reflections and physically accurate paint materials.

Product showcases and virtual showrooms extend the configurator concept to furniture, electronics, fashion, and luxury goods. Customers interact with 3D product models at a level of detail that static images or pre-rendered videos cannot match.

Training and simulation applications benefit from pixel streaming because trainees can access complex simulation environments from any device without specialized hardware. Medical training, industrial equipment operation, emergency response scenarios, and military simulations all use this delivery model.

Cloud gaming demos let game studios distribute playable demos of their Unreal Engine games without requiring players to download anything. Studios can share demo links on social media, embed playable previews in their website, or offer limited play sessions at trade shows from any internet-connected device. This is particularly valuable for marketing upcoming titles.

Digital twins of factories, cities, infrastructure, and natural environments combine real-time sensor data with Unreal Engine's rendering to create interactive monitoring and analysis tools accessible from a browser.

Server-Side Rendering vs Browser-Based Engines

Understanding the fundamental difference between server-side rendering (pixel streaming) and client-side rendering (browser-based engines) is essential for making the right architectural choice for your project.

Browser-based game engines like Three.js, Babylon.js, PlayCanvas, Phaser, and Unity WebGL run entirely in the user's browser. They use WebGL or WebGPU to access the device's local GPU and render frames directly. Every asset (textures, 3D models, audio files, scripts) is downloaded to the client device. The browser's JavaScript engine executes the game logic, and the local GPU handles rendering. This approach has significant advantages: there is zero server cost per concurrent player, input response is instantaneous with no network latency involved, the application works offline after assets are cached, and you can scale to millions of simultaneous users because each user's device does its own work.

Pixel streaming inverts this model entirely. The server does all the work, and the client just displays video. This creates a different set of advantages and tradeoffs.

Visual fidelity. Unreal Engine's renderer is among the most advanced in the industry. Nanite handles virtualized micropolygon geometry that would be impossible to stream to a browser. Lumen provides real-time global illumination that far exceeds what WebGL screen-space approximations can achieve. MetaHuman delivers photorealistic digital characters. None of these features have equivalents in browser-based rendering. If your project demands this level of visual quality, pixel streaming is the only way to deliver it through a browser.

Hardware independence. The user's device only needs to decode an H.264 video stream, which every modern browser handles efficiently through hardware-accelerated video decode. A five-year-old smartphone can display the same photorealistic scene that would require a $2,000 desktop GPU to render locally.

Asset protection. With browser-based engines, all game assets are downloaded to the client and can be inspected, extracted, and copied by anyone with browser developer tools. With pixel streaming, assets never leave the server. Only compressed video frames reach the client.

Engine capabilities. Unreal Engine's physics engine (Chaos), animation system, world partition for enormous open worlds, Niagara particle effects, and AI navigation all work normally because the application runs natively on the server. Browser-based engines have simpler equivalents of these systems, constrained by the browser's execution environment.

The critical tradeoffs are cost, latency, and scale. Each concurrent pixel streaming user requires dedicated GPU resources on the server, which translates to real infrastructure cost. Network latency adds 30 to 80 milliseconds to every interaction, making the technology unsuitable for competitive multiplayer games or applications requiring instant response. And scaling to thousands of concurrent users requires thousands of GPU instances, which is expensive compared to browser-based engines where additional users cost nothing on the server side.

Getting Started with Pixel Streaming

The journey from an existing Unreal Engine project to a working pixel streaming deployment involves several steps, each with its own configuration options and potential complications.

In the Unreal Editor, you begin by enabling the Pixel Streaming plugin. In UE 5.4 and later, there are two plugin options: the original Pixel Streaming plugin and the newer Pixel Streaming 2 plugin, which uses a refactored architecture with improved modularity and extensibility. Both work for basic streaming, but new projects should prefer Pixel Streaming 2 as it represents the future direction of the feature.

After enabling the plugin and restarting the editor, you configure the streaming parameters. Key settings include the target resolution, frame rate cap, encoding bitrate range, and whether to use H.264 or H.265 encoding. You also configure the WebRTC signaling server URL and the ports the application will use for communication.

Packaging the project for server deployment requires selecting a platform target. Windows Server and Linux are both supported, though Linux is more common for cloud deployments because of lower overhead and better container support. The packaged build includes the Unreal application and can run headless (without a monitor) using a virtual display adapter on the server.

On the server, you deploy the packaged Unreal application alongside the signaling server. The standard port configuration uses port 80 for the web frontend, port 8888 for signaling WebSocket connections, and a range of UDP ports (typically 49152 to 65535) for WebRTC media transport. You need to configure your firewall and security groups to allow traffic on these ports.

Testing locally before deploying to the cloud is straightforward. You can run the Unreal application, signaling server, and frontend all on the same machine and connect from a browser on the local network. This lets you verify that the streaming pipeline works before introducing the complexity of cloud infrastructure.

Our detailed setup guide walks through the complete process from plugin installation through deployment and testing, including common issues and their solutions.

Cloud Hosting and Scaling Strategies

Production pixel streaming deployments run in the cloud because they need GPU instances that can be provisioned and terminated on demand based on user load. The three major cloud providers all offer suitable GPU instances, though AWS has the most mature ecosystem for this use case.

On AWS, the most common instance types for pixel streaming are the G4dn family (NVIDIA T4 GPUs) and the G5 family (NVIDIA A10G GPUs). A single g4dn.xlarge instance provides one T4 GPU with 16GB of video memory, 4 vCPUs, and 16GB of system memory. It can handle one to four concurrent streaming sessions depending on scene complexity, target resolution, and quality requirements. On-demand pricing for g4dn.xlarge is approximately $0.53 per hour in US regions, though spot instances can reduce that by 60 to 70 percent for interruptible workloads.

Google Cloud Platform offers equivalent capability through N1 instances with attached NVIDIA T4 GPUs, and Azure provides NV-series virtual machines with NVIDIA GPUs. The configuration principles are similar across providers, though the specific instance setup, networking, and auto-scaling mechanisms differ.

Scaling beyond a single instance requires a matchmaker component that tracks which GPU instances are running, how many sessions each is handling, and which have capacity for new connections. When a user connects, the matchmaker assigns them to an available instance. When demand grows beyond current capacity, the matchmaker triggers the auto-scaling system to launch additional GPU instances. When sessions end and instances become idle, the system terminates them to reduce cost.

TensorWorks' Scalable Pixel Streaming (SPS) provides a production-ready implementation of this architecture, running on Amazon Elastic Kubernetes Service (EKS). It handles container orchestration, matchmaking, auto-scaling, health monitoring, and session management. For teams that do not want to build their own orchestration layer, SPS significantly reduces the engineering effort required for production deployment.

Fully managed hosting platforms offer an even simpler path. Services like Arcware Cloud and PureWeb let you upload a packaged Unreal build and handle everything else, from GPU provisioning and scaling to the web client and session management. Pricing for managed platforms typically runs between $0.50 and $1.00 per stream-hour per concurrent user, which is higher than raw cloud infrastructure but eliminates the engineering and operations burden.

TURN servers are a critical infrastructure component that is easy to overlook. Some users sit behind restrictive NATs or corporate firewalls that prevent direct WebRTC connections. A TURN server acts as a relay, forwarding media traffic between the client and server when a direct connection cannot be established. Without TURN servers, a percentage of your users, typically 10 to 15 percent, will be unable to connect. Our hosting and scaling guide covers TURN configuration, cost modeling, and architectural best practices in detail.

Performance, Latency, and Stream Quality

The quality of a pixel streaming experience depends on three interacting factors: encoding quality, network conditions, and client-side decode performance. Optimizing all three is necessary for a smooth user experience.

Encoding configuration controls the tradeoff between visual quality and bandwidth requirements. The key parameter is the target bitrate, typically set between 10 and 20 Mbps for a 1080p stream at 60fps. Higher bitrates produce cleaner images with fewer compression artifacts but require more bandwidth from the user's connection. The minimum frame rate should be set to match the maximum frame rate (both at 60fps for most applications) to prevent the encoder from dropping frames during complex scenes. Rate control mode should be set to CBR (Constant Bit Rate) for the most predictable streaming behavior, or VBR (Variable Bit Rate) if bandwidth is constrained and you want the encoder to allocate more bits to complex frames.

Network requirements set the practical limit on who can use your application. A comfortable 1080p streaming experience requires approximately 15 to 20 Mbps of sustained downstream bandwidth and less than 50 milliseconds of round-trip latency between the client and the GPU server. Users on slower connections will see increased compression artifacts, resolution drops (if adaptive quality is enabled), and frame skipping. Users with higher latency will notice a delay between their input and the visible response, which becomes distracting above 100 milliseconds and unusable for fast-paced interaction above 200 milliseconds.

Edge deployment is the most effective strategy for reducing latency. Running GPU servers in data centers geographically close to your users minimizes the physical distance that packets must travel. If your audience is primarily in North America, deploying in AWS regions like us-east-1, us-west-2, and ca-central-1 provides good coverage. A global audience requires more points of presence, which increases infrastructure complexity and cost.

Adaptive streaming is a technique where the server dynamically adjusts the stream resolution and bitrate based on measured network conditions. If the system detects packet loss, increasing round-trip time, or insufficient bandwidth, it can reduce the resolution from 1080p to 720p or lower the bitrate to maintain a smooth frame rate at the expense of visual quality. The Pixel Streaming plugin supports adaptive quality out of the box, though tuning the thresholds and response curves requires experimentation with your specific content and target audience.

Client-side decode performance is rarely a bottleneck on modern devices. Hardware-accelerated H.264 decode is supported by virtually every browser on every platform, including mobile devices from the last five years. The decode process adds minimal latency, typically 1 to 3 milliseconds. However, very high resolution streams (4K at 60fps) can strain older mobile devices, and some browsers have decode throughput limits that you may encounter with extreme configurations.

The total end-to-end latency from user input to visible response in a well-optimized deployment typically breaks down as follows: input capture and transmission (5 to 10ms), network transit to server (10 to 40ms depending on distance), server-side processing and rendering (8 to 16ms at 60fps), video encoding (1 to 2ms), network transit back to client (10 to 40ms), and video decode and display (1 to 3ms). The total ranges from about 35 milliseconds in ideal conditions to 110 milliseconds in typical deployments.

Mobile and Cross-Device Delivery

Cross-device accessibility is one of pixel streaming's most compelling advantages. The same Unreal Engine application, rendered at maximum quality on a GPU server, reaches any device with a browser and a network connection. No app store submission, no platform-specific builds, no minimum hardware requirements on the client side.

Mobile browsers on iOS (Safari) and Android (Chrome, Samsung Internet, Firefox) all support the WebRTC stack required for pixel streaming, including H.264 video decode, Opus audio decode, and data channel communication. A pixel streaming session works on a modern smartphone without any special configuration on the client side.

However, mobile introduces considerations that require attention in both the server configuration and the frontend client design.

Touch input mapping requires careful design. Desktop Unreal applications typically expect mouse and keyboard input, while mobile users interact through touch gestures. The frontend JavaScript must translate touch events (taps, drags, pinches, multi-touch gestures) into the input format the Unreal application expects. For exploration and visualization applications, mapping single-touch drag to camera rotation and pinch to zoom works intuitively. For game-like applications, you may need on-screen virtual joysticks and action buttons, which the frontend renders as HTML/CSS overlays on top of the video stream.

Adaptive resolution is particularly important on mobile. Streaming 1080p video to a phone with a 6-inch screen wastes bandwidth without visible quality improvement. Reducing the streaming resolution to 720p for mobile clients cuts bandwidth requirements roughly in half while maintaining perceived quality on a small screen. The frontend can detect the client's screen size and request an appropriate resolution from the server.

Network variability on mobile connections (4G LTE and 5G) is higher than on fixed broadband. Latency can spike when transitioning between cell towers, and bandwidth can fluctuate significantly. Aggressive adaptive quality settings help maintain a playable experience through these fluctuations.

Battery impact is actually favorable for pixel streaming compared to running a graphically intensive local application. Video decode consumes far less power than local 3D rendering. A pixel streaming session typically uses less battery than playing a locally-rendered 3D game on the same device, though it uses more than watching a non-interactive video because of the continuous input capture and data channel communication.

Our guide on Unreal Engine games on mobile covers mobile delivery strategies including both pixel streaming and native mobile deployment, with practical recommendations for each approach.

AI Tools for Unreal Engine Development

The landscape of AI-assisted development tools for Unreal Engine has expanded significantly in 2025 and 2026. These tools address different aspects of the development workflow, from code and Blueprint generation to asset creation and level design.

Engine-integrated AI assistants represent the most sophisticated category. Ultimate Engine CoPilot by BlueprintsLab, which reached production readiness in April 2026, operates directly inside the Unreal Editor with over 1,050 tool actions across 56 engine categories. Unlike general-purpose AI coding assistants that suggest text, it executes actions directly within the engine, placing Blueprint nodes, wiring connections, setting property values, compiling code, and building complex systems like Niagara particle effects, behavior trees, and material graphs through natural language commands. It also includes voice control and the ability to run multiple concurrent AI agents within the editor.

General AI coding assistants like GitHub Copilot, Cursor, and Claude understand Unreal Engine's C++ codebase and can assist with writing gameplay code, engine modifications, shader code (HLSL), build system configuration (Build.cs files), and project settings. They are most useful for boilerplate reduction, API exploration, debugging compilation errors, and generating repetitive code patterns. They work alongside the editor rather than inside it, assisting with the text-based development workflow.

AI asset generation tools are becoming practical for certain asset types. AI image generators can produce textures, concept art, skyboxes, UI elements, and reference images. AI 3D model generators have improved but remain below production quality for most game assets, particularly for models that need to work with Unreal's material, LOD, and collision systems. AI audio tools can generate sound effects, ambient soundscapes, and music tracks.

Our detailed guide to AI tools for Unreal development covers the current tool landscape, practical integration workflows, and how to evaluate which tools provide genuine productivity gains versus novelty.

Choosing Between Unreal and Native Web Engines

The decision between delivering Unreal Engine content via pixel streaming versus building with a browser-native engine depends on your project's specific requirements, audience, and budget. Neither approach is universally better.

Choose Unreal with pixel streaming when visual fidelity is the primary requirement. Architectural visualization, automotive configurators, cinematic experiences, and product showcases where photorealistic rendering directly impacts business outcomes are strong use cases. Also choose Unreal when your application relies on engine-specific features like Nanite, Lumen, MetaHumans, Chaos physics, or the world partition system for enormous open worlds, none of which have browser equivalents. Asset protection is another reason, since pixel streaming keeps all models, textures, and code on the server. Finally, Unreal makes sense when your expected concurrent user count is manageable (dozens to low hundreds) and your users have reliable broadband connections.

Choose a browser-native engine when you need to support thousands or millions of simultaneous users without per-user server costs. Browser-native engines also win when low-latency input response is critical (competitive multiplayer, rhythm games, precision platformers), when users may be on slow or unreliable connections, when offline play capability is required, or when the visual requirements can be met with WebGL or WebGPU rendering, which is increasingly capable for stylized and mid-fidelity content.

Consider a hybrid approach when your requirements span both categories. Some teams develop their core experience in Unreal Engine, using its superior editor and content pipeline, and then offer two delivery modes: a pixel-streamed version for the premium experience on capable connections, and a simplified browser-native version (often built with Three.js or Babylon.js) for broader reach. This approach increases development effort but maximizes audience coverage.

The comparison with Unity's web delivery options is particularly relevant, since Unity offers a middle ground through its WebGL export, which runs natively in the browser but with more limited visual fidelity than Unreal's server-rendered approach.

Budget is often the deciding factor. Pixel streaming has ongoing infrastructure costs that scale linearly with concurrent users, while browser-native engines have essentially zero marginal cost per user after initial development. For commercial applications where each user interaction generates revenue (product sales, real estate, automotive), the per-user cost is easy to justify. For free content aimed at broad audiences, the economics of pixel streaming rarely work out unless the user count is low.

Explore This Topic

Pixel Streaming Guides

Comparisons and Strategy

Development and Platforms