Refresh as Often as the Data Changes
A video stream has to be re-rendered and re-encoded before it can change — and the encode is the slow half, minutes on a long deck. HTML playback cycles the same rendered slides client-side from a manifest instead of playing a video, which takes the encode out of the loop entirely. A refresh costs seconds rather than minutes, so it can run as often as your data needs, and updated slides reach the screen the next time the loop wraps. It is built for content where a once-a-day render is not enough: live prices, fast-moving feeds, anything that goes stale quickly.
A per-slideshow setting · Switch modes any time
Built for the Moment the Data Changes
Not every screen can afford to wait on a video encode. HTML playback exists for the ones that can’t.
Refreshes Cost Seconds, Not Minutes
Push a new value over the API and the next refresh carries it to the screen. With no encode step in the way, that refresh is cheap enough to run on a tight cadence instead of once a day.
Built for Fast-Changing Feeds
A ticker, a live scoreboard, a fast-moving price list — content that would otherwise mean re-rendering and re-encoding a stream every few seconds.
Still Just Slides
Nothing about how you build a slideshow changes. HTML playback plays the same rendered slides, with the same transitions — it changes how updates reach the screen, not what a slide is.
How It Works
The player runs on the screen instead of inside a video file.
Slides Render as Images
Each slide is still rendered the same way as any InfoSlides slide — but published as an image or short clip in a manifest, not baked into a video file.
The Screen Cycles the Manifest
A small player on the screen fetches the manifest and cycles through it — crossfading between slides, holding each for its configured duration — the same visual rhythm as a video stream.
A New Version Swaps In at the Loop Boundary
When your data changes, a new manifest is prepared in the background and swapped in cleanly the next time the loop wraps — never mid-slide, never a flash of missing content.
The trade you’re making
It Wins on Immediacy. It Needs a Screen That Can Run It.
HTML playback is not simply “better” than video stream — it is a different trade. A video stream plays on anything that can open an HLS URL, hardware with no browser included. HTML playback needs the display itself to run a small player — a modern smart-TV app, an embedded browser, or any web browser opened at a stream’s embed player URL. On a screen that cannot do that, HTML playback simply is not an option.
If your screens are hardware signage boxes or older TVs with no app platform, stay on video stream and let dynamic slides refresh on their normal schedule. If your screens can run a modern app or browser and the content genuinely changes faster than a render cycle can keep up, HTML playback is built for exactly that gap.
Read the case for video stream →Wins on immediacy · needs a screen that can run the player
Video stream
Wins on reach · plays on any screen that speaks HLS, browser or not
HTML Playback — Common Questions
How fast does HTML playback show a data change on screen?
Your data is picked up by the next refresh, and the updated slides swap in the next time the slideshow loop wraps. The refresh itself still happens — slides are prepared server-side in both modes — but it skips the video encode, which is the expensive half, so it can run far more often than a video stream's could. This is not an instantaneous per-second update: expect it to be bounded by your refresh cadence and your loop length.
Does HTML playback work on the hardware I already have?
Only if the screen can run a modern web browser or player — a smart-TV app, an embedded browser, or a browser opened at the stream's embed player URL. It does not work on hardware signage boxes or older TVs with no browser or app platform at all; those need video stream.
Is HTML playback better than video stream?
Not universally — it's a different trade. HTML playback wins on refresh cost: with no encode step, content can be updated far more often. Video stream wins on reach: it plays on any screen that speaks HLS, including hardware with no browser. Pick based on what your content and your screens actually need.
What happens if the screen loses its network connection?
The player keeps cycling whatever it already loaded rather than freezing or blanking, and a slide whose asset fails to load is skipped without ever showing broken content — the previous slide simply stays on screen. Playback resumes normally once the connection returns.
Can I switch a slideshow between video stream and HTML playback?
Yes, any time, from the slideshow's settings. The new mode takes effect on the slideshow's next render — hit Re-render on the slideshow if you want it to reach your screens straight away rather than waiting for the next scheduled refresh. There is no manual re-export or re-upload step either way.
Does HTML playback cost more?
No. It's a playback setting available on the same plans as video stream, not a separate add-on.
Get Data to the Screen the Moment It Changes
A per-slideshow setting — switch a slideshow to HTML playback, or switch it back, any time. Live data slides need a paid plan, from €9 per month.
Get Started FreeNot sure this is the right mode? See video stream mode · Push live data over the API · Compare plans