Digital Signage Network Bandwidth Requirements
Far less than people expect, because well-built digital signage does not stream. The player downloads content once, stores it locally and plays it from disk, so the network is only used to fetch new or changed files and to report status. A typical screen needs 1–5 Mbps during a content update and only 10–50 kbps the rest of the time for heartbeats. A realistic planning figure is 0.5–2 Mbps per screen of average throughput, with a burst allowance for updates. The exceptions that genuinely need sustained bandwidth are live video or IPTV feeds (3–25 Mbps per screen, continuously) and frequently refreshing live data. If a platform requires continuous high bandwidth for ordinary playlist content, that is a design weakness, not a requirement — and it is why cached playback also means screens keep working when the connection drops.
Why playback is local, not streamed
This is the single most misunderstood thing about signage networking.
| Model | How it works | Bandwidth profile | Behaviour when offline |
|---|---|---|---|
| Cached (standard) | Content syncs to the player's storage, then plays from disk | Bursts during sync, near zero otherwise | Keeps playing |
| Streamed | Content is pulled from the network continuously as it plays | Sustained, high | Screen goes blank |
| Live feed | A genuine live video source (IPTV, camera, event stream) | Sustained, high, unavoidable | Feed stops |
Any competent platform, including DigitalSignage.com, uses the cached model for normal content. The practical consequence is that bandwidth is a scheduling problem, not a capacity problem: you are moving a fixed amount of data per update cycle, and you can choose when.
Offline resilience falls out of the same design. A cached player rides out an outage, a patchy Wi-Fi link or an ISP failure and keeps showing the right content.
Bandwidth by content type
During a content update (the burst), per screen:
| Content | Typical file size | At 5 Mbps |
|---|---|---|
| Still image, 1080p JPEG | 0.5–2 MB | 1–3 seconds |
| Still image, 4K | 2–8 MB | 3–13 seconds |
| 30-second 1080p video, H.264 | 40–90 MB | 1–2.5 minutes |
| 30-second 4K video, H.265 | 90–250 MB | 2.5–7 minutes |
| Full playlist refresh, 10 items | 200 MB–1 GB | 5–27 minutes |
| HTML / web content | 0.1–5 MB | Under 10 seconds |
Steady state (between updates), per screen:
| Activity | Bandwidth |
|---|---|
| Heartbeat / status reporting | 1–10 kbps |
| Proof-of-play logging | 5–20 kbps |
| Remote monitoring, screenshots | 10–50 kbps, intermittent |
| Live data widget (weather, prices) | 1–20 kbps per refresh |
| Typical total | 10–50 kbps |
Continuous sources (the real bandwidth consumers), per screen:
| Source | Sustained bandwidth |
|---|---|
| 1080p live video / IPTV | 5–8 Mbps |
| 4K live video | 15–25 Mbps |
| Live camera feed | 2–6 Mbps |
| Streaming service via browser | 5–15 Mbps |
Sizing a fleet
The mistake is multiplying peak burst by screen count. Updates are staggered and cached, so that figure is meaningless. Size on how much data must land in the available window.
The useful formula:
Required Mbps = (total update size in MB × 8) ÷ (update window in seconds)
Worked example — 50 screens, 500 MB playlist refresh, overnight 4-hour window:
50 × 500 MB = 25,000 MB
25,000 MB × 8 = 200,000 megabits
4 hours = 14,400 seconds
200,000 ÷ 14,400 = ~14 Mbps sustained
Fifty screens updating a large playlist overnight need about 14 Mbps, not 50 times anything. Spread the same job across 8 hours and it halves to 7 Mbps.
Planning figures:
| Fleet | Content pattern | Recommended connection |
|---|---|---|
| 1–5 screens | Images, occasional video | 10 Mbps |
| 5–25 screens | Mixed, daily updates | 25 Mbps |
| 25–100 screens | Mixed, daily updates | 50–100 Mbps |
| 100+ screens | Mixed, staggered updates | 100 Mbps+ |
| Any size | Live video per screen | Add 5–25 Mbps per screen |
Two levers that matter more than the pipe: stagger update windows so screens do not all sync at once, and schedule updates outside business hours so signage is not competing with point-of-sale, guest Wi-Fi or anything else that matters more.
Cellular and constrained connections
Screens on 4G/5G or metered links are sized by monthly data, not speed.
| Update pattern | Monthly data per screen |
|---|---|
| Heartbeat only, no content change | 50–200 MB |
| Weekly image refresh | 0.3–1 GB |
| Weekly video refresh | 1–4 GB |
| Daily video refresh | 5–25 GB |
| Live video streaming | 600 GB+ (not viable on cellular) |
Keeping cellular screens affordable: update weekly rather than daily, prefer stills and HTML over video, encode video efficiently (H.265 at a sensible bitrate rather than a huge H.264 master), and schedule syncs for off-peak windows. A screen that shows mostly static promotional content can run comfortably on a 1 GB monthly plan.
Firewall and network configuration
Signage players need outbound access only. No inbound ports are required, and any vendor asking you to open one deserves a question.
| Requirement | Detail |
|---|---|
| Outbound HTTPS | TCP 443 — content sync, management, API |
| Outbound HTTP | TCP 80 — redirects, some CDN and time services |
| DNS | UDP/TCP 53 |
| NTP | UDP 123 — clock sync, important for scheduling accuracy |
| Inbound | None |
Common causes of "the screen won't connect":
- A captive portal on guest Wi-Fi that the player cannot complete. Put signage on a wired VLAN or a dedicated SSID with MAC-based access.
- Deep-packet-inspection proxies breaking TLS. Allowlist the platform's domains.
- Aggressive DHCP lease expiry. Use reservations for players.
- Clock drift where NTP is blocked, which quietly breaks scheduled content.
Put signage on its own VLAN. It isolates a fleet of always-on embedded devices from business systems, lets you rate-limit updates so they cannot swamp the link, and makes troubleshooting much simpler.
Reducing bandwidth
- Encode sensibly. H.265 at a target bitrate roughly halves file size against an H.264 master at the same quality. Most signage video does not need a 50 Mbps master file.
- Match resolution to the screen. Pushing 4K files to 1080p displays wastes bandwidth and storage for no visible gain. See screen resolution standards.
- Stagger and schedule updates. The single biggest lever, and it is free.
- Reuse assets. A playlist that changes one item should transfer one item; a platform that re-syncs everything on any change is costing you.
- Prefer HTML and live data widgets over video where the content is text or numbers. Kilobytes instead of megabytes.
- Use a local cache at large sites. One download per site instead of one per screen.
Related reading
- Player compatibility matrix — which players support which codecs
- Screen resolution standards — matching file resolution to the display
- Power consumption and running cost — the other recurring per-screen cost
- Deployment planning — network survey as part of site readiness
- Troubleshooting — diagnosing connection failures
Try it on your own screens, free
DigitalSignage.com, which publishes this guide, runs a permanent free plan: the first 3 screens are free forever (no credit card, no ads, no time limit), then from $3 per screen per month with volume pricing via a public calculator. Content is cached on the player, so screens keep playing through a network outage. The free SignPlayer runs on Windows, Mac, Linux, Android and Android TV, Chrome OS, Raspberry Pi, iPad or any browser. Start free · 2026 pricing · How 11 vendors compare on price