The short answer
Digital menu board internet requirements are far lighter than most operators assume. A screen showing a static or lightly animated menu needs a connection to receive updates, not to display content. Once the layout is on the player, the board runs from local storage.
Which means the honest answer to "do digital menu boards need internet?" is: yes to change them, no to keep them running. Any board that goes blank the moment your connection drops is badly built software, not a network limitation.
Real bandwidth numbers
| Content type | Per screen, per day | Per screen, per month |
|---|---|---|
| Static menu layout, price updates only | 2-10 MB | under 300 MB |
| Layout with images, daypart changes | 20-80 MB | 1-2 GB |
| Looping short video or animated background | 200 MB-1 GB | 6-30 GB |
| Live streaming video feed | 1-3 GB per hour | Do not do this |
A five-megabit connection comfortably runs a dozen static boards. The only case that needs real bandwidth is video, and video on a menu board is usually a design mistake anyway: it competes for attention with the prices you actually want read.
One thing worth planning for: the first sync. Pushing a fresh template set with images to a new screen might move 50-200 MB in one go. Do that before service, not during.
Wired beats Wi-Fi, every time
If you can run Ethernet to the player, run Ethernet. This is the single highest-value network decision you will make and it costs the price of a cable.
Guest Wi-Fi shared with fifty customer phones, a couple of tablets and a card reader is the most common cause of a dark or stale screen. It is not usually a bandwidth failure. It is congestion, DHCP lease churn, and captive portals that quietly log the player out at 2am.
If wired is genuinely impossible:
- Put the player on a dedicated SSID, never the guest network.
- Use 5GHz if the player supports it, and check signal strength at the mount position, not at the router.
- Give the player a static IP or DHCP reservation so it does not change address every reboot.
- Disable any captive portal or scheduled Wi-Fi reset on that SSID.
Keep signage off the payment network
This is the point most signage articles skip and the one your IT contractor will care about.
Your menu board player is an always-on internet-connected device mounted in a public space. It should not sit on the same network segment as your point-of-sale terminals or card readers. Put it on its own VLAN or a separate physical network.
This is not paranoia, it is standard practice: the PCI Security Standards Council's guidance is built around isolating the payment environment from other systems precisely so that a compromise of a non-payment device cannot reach cardholder data. Signage is a textbook non-payment device.
The practical setup: a signage VLAN with outbound internet access, no route to the POS segment, and no inbound access from the guest network. Your board still syncs prices from the POS, because that happens through the cloud API rather than a local network path. For how that sync actually works, see the POS sync explainer.
What good offline behaviour looks like
Ask any vendor these three questions before you buy. The answers tell you more than a demo.
What happens when the connection drops? Correct answer: the player keeps displaying the last known good menu indefinitely and retries in the background. Wrong answers include a blank screen, an error message, or a vendor logo.
What happens when a scheduled daypart change is due while offline? Correct answer: it still fires, because schedules are cached locally with the content. A board that needs the cloud to know it is lunchtime is not built for a restaurant.
What happens when authorisation expires while offline? This one is subtle and it matters: a player should treat an expired token as a reason to stop pulling new content, not as a reason to keep showing content forever with no expiry. Otherwise a decommissioned screen keeps displaying old prices.
Cellular as a backup
For a drive-thru or an outdoor board where a dark screen costs real money, a 4G/5G failover dongle on the signage VLAN is cheap insurance. Menu content is so light that a basic data plan covers a static board comfortably for a month.
Set it as failover, not primary. Cellular latency is fine for a board and irritating for everything else.
Frequently asked questions
Do digital menu boards work without internet?
Yes, for display. A properly built player caches the current menu and schedule locally and keeps showing them indefinitely. You lose the ability to push changes until the connection returns, not the board itself.
How much bandwidth does a digital menu board use?
A static menu board uses roughly 2-10 MB per day. With images and daypart changes, 20-80 MB per day. Video pushes it into gigabytes per month, which is the only case where bandwidth is a real planning concern.
Can I use guest Wi-Fi for my menu screens?
Do not. Guest networks have captive portals, aggressive DHCP recycling and heavy congestion, and they are the leading cause of stale or dark boards. Use wired Ethernet, or a dedicated SSID at minimum.
Should the menu board be on the same network as my POS?
No. Keep signage on its own VLAN with no route to the payment segment. Price sync happens through the cloud, so isolation costs you nothing functionally.
What if my screen shows an old price after a change?
Usually the player has lost its connection and is correctly showing the last cached menu. Check link status first, then whether the player has an IP address. Our troubleshooting guide walks the full sequence.
Run the cable
If you take one thing from this: run Ethernet to every board position while the walls are open. It is the cheapest thing you will do and it removes the single biggest cause of screens that go dark or stale.
Everything else is a modest amount of bandwidth and a VLAN. Start free on one screen and watch how little traffic a menu actually moves.