Add a URL and the device opens it in a browser built for signage: full screen, no tabs, no address bar, no navigation.
Unlike an uploaded file, a page is not stored on the device. It loads live from its source each time it plays, so screens always show the current version. It also means a page whose source is unreachable does not display at all, and the screen moves on to the next item.
Where the page is rendered
Site rendering method, on the content item under Advanced, decides this.
Render on player is the default and what hardware players always do. The device fetches the URL, runs its JavaScript, and shows the result live. Requests come from the device’s own IP address, so a page restricted by IP has to allow the device, and anything on your local network is reachable.
Screenshot from server is available on Screenly Anywhere screens only. We load the page on our infrastructure, screenshot it, and send the image. Requests then come from our servers, not the device, so anything on your local network becomes unreachable and IP allowlists need to name us instead.
Use the second when a page will not load reliably on lower-power hardware. Do not use it for anything that has to be live to the second: a screenshot refreshes on an interval rather than updating continuously.
What a page has to do
Load in a reasonable time. A page heavy with JavaScript renders slowly on a low-power device, and a page still loading when its slot ends never gets seen. Give a heavy dashboard 30 or 40 seconds rather than the default 10.
On Screenly Anywhere, two further requirements, and a page failing either will not display:
Serve over HTTPS. Plain HTTP does not load.
Allow being framed. A site whose Content-Security-Policy forbids embedding cannot be shown.
Local and intranet pages
A page on your own network works, and this is the route for content that must not leave your premises.
Add its address, for example http://192.168.1.50/dashboard. Our servers cannot reach it, so you will get Content could not be verified: choose Add anyway. The screen fetches it directly over the local network, and the content never passes through us.
Two conditions. The player has to be on a network segment that can reach the server, so a player on another VLAN or at a remote site cannot. And the source must be an HTML page: to show a local image or PDF, wrap it in a minimal page and point Screenly at that.
Locally served content is not cached either. If the server goes down, the content stops appearing. For something that must survive an outage, upload it as a file instead.
When a page looks wrong
Zoom level, under Advanced, scales the page from 25% to 500%, with 100% being its natural size. This is the fix for a page designed for a laptop that reads as tiny across a room, and it needs player client 4.1.0 or newer, which is separate from the ScreenlyOS release number.
Cookie banners and navigation furniture cannot be dismissed by a setting. Publish the content another way, or use JavaScript injection to remove them on load.