Bandwidth is the most common bottleneck for Plex — especially when sharing your library with remote users. Understanding how much bandwidth each stream actually needs, and what happens when there isn’t enough, is essential for reliable streaming.
How Much Bandwidth Does Plex Actually Use?
It depends entirely on the file being played and whether transcoding is involved:
- 1080p H.264 (typical movie) — 8–20 Mbps for direct play. The actual bitrate of the file
- 4K HDR HEVC (Blu-ray quality) — 40–80 Mbps for direct play. Some remuxes peak at 100+ Mbps
- 4K SDR (streaming quality) — 15–25 Mbps. Most “4K” content from streaming services
- 720p transcode — 2–4 Mbps. What most mobile users get
- Audio only (music) — 0.3–1.5 Mbps depending on format
Upload vs. Download
For local streaming (same network), bandwidth is rarely an issue — Gigabit Ethernet handles everything. The bottleneck hits with remote access:
- Your upload speed is what limits remote streaming. ISPs often give asymmetric speeds (e.g., 300 Mbps down / 20 Mbps up)
- With 20 Mbps upload, you can serve one 1080p direct play stream reliably, or 4–5 transcoded 720p streams
- Two remote users watching 4K simultaneously need ~80–160 Mbps upload — most residential connections can’t do this
Plex Bandwidth Settings
Plex has several bandwidth controls:
Server-Side Settings
- Remote stream bitrate limit — Settings → Remote Access. Caps the quality for all remote users. Useful when your upload is limited
- Per-user bandwidth limit — Under user sharing settings. Set different limits for different users based on their connection quality
- LAN networks — Define which subnets are “local” so they get unlimited quality while remote users are capped
Client-Side Settings
- Remote streaming quality — Each client app has its own quality setting. Default is often “Recommended” (720p 4 Mbps), which triggers transcoding even when the connection could handle more
- Set to Maximum/Original — Tell users to set remote quality to Maximum or Original for direct play. This is the #1 fix for unnecessary transcoding
The Transcoding Trap
Here’s the cycle that kills most Plex setups:
- Remote user’s client defaults to “720p 4 Mbps” quality
- Server transcodes a 30 Mbps file down to 4 Mbps
- CPU/GPU gets loaded; other streams suffer
- Meanwhile, the user’s connection could have handled the original file just fine
The fix: tell every remote user to go into their Plex app settings and set streaming quality to Maximum. If their connection can’t handle it, Plex will adapt. But starting low forces unnecessary transcoding.
Monitoring Bandwidth Usage
Use Tautulli (free) to see exactly what’s happening:
- Which users are direct playing vs. transcoding
- Actual bandwidth per stream
- Historical bandwidth patterns (peak hours, heavy users)
- Which files cause the most transcoding
Solutions for Limited Upload
If your upload speed can’t handle the demand:
- Pre-transcode with Tdarr — Create optimized versions of your library in advance. A 1080p H.264 copy at 8 Mbps serves most remote users without real-time transcoding
- QoS on your router — Prioritize Plex traffic (port 32400) so other household upload activity doesn’t starve streams
- Upgrade your ISP plan — Many ISPs now offer symmetric fiber (same up and down). Worth it if you serve multiple remote users
- Offload transcoding — Services like PlexBeam move the transcode work to a remote GPU, reducing both CPU load and bandwidth requirements by transcoding closer to the viewer
- Cloud Plex server — Host your server in a datacenter with symmetric Gigabit. Solves upload problems but adds storage costs
Bandwidth Math Cheat Sheet
Quick reference for planning your setup:
- 1 remote 1080p direct play stream: needs ~20 Mbps upload
- 1 remote 4K direct play stream: needs ~80 Mbps upload
- 1 remote 720p transcoded stream: needs ~4 Mbps upload
- 3 simultaneous remote 1080p streams: needs ~60 Mbps upload
- Music streaming: needs ~1 Mbps per user
Test your actual upload speed at speedtest.net (use the upload number, not download). Real-world throughput is typically 80–90% of advertised speeds due to protocol overhead.