HTML5 overlays: how browser-based graphics reach your stream
Nearly every modern live graphics system now renders in a browser engine. This page explains what an HTML5 overlay is, how transparency survives the trip into your encoder, how the graphics stay in sync with a control panel, and where the technique runs out of road.
What an HTML5 overlay is
It is an ordinary web page whose background is never painted. Every graphic — the strap, the bug, the ticker — is a DOM element positioned on a 1920×1080 canvas. Because the page paints nothing behind them, every other pixel is transparent.
Your encoder opens that page in an embedded browser (OBS uses CEF, the Chromium Embedded Framework) and composites the result over your scene, honouring the alpha channel. From the encoder’s point of view it is just another source with transparency, like a PNG that moves.
How the graphics change while on air
The page opens once and stays open. When the operator presses TAKE, a command travels over a WebSocket to the page, which adds a class or updates a value, and CSS animates the element on screen. Nothing is reloaded and no file is written.
That is what makes live data possible: a score can tick over, a clock can run and a name can change while the graphic is still on air, because the page is a running application rather than a rendered file.
Performance rules that matter
- Animate transform and opacity only. These are composited on the GPU. Animating width, height, top or left forces layout on every frame.
- Avoid animated box-shadow and filter. They repaint large areas and are the most common cause of a stuttering overlay.
- Keep the DOM small. A few dozen elements is normal. A few thousand is a stream that drops frames.
- Do not poll. A timer that redraws every 100 ms costs the same whether anything changed or not; push updates over the socket instead.
- Match the canvas. Build at the encoder’s resolution so the browser source is never rescaled, which would soften every edge of type.
Where HTML5 is not enough
A browser source is composited by your encoder, which means the graphics exist only inside that encoder. If you need to feed a vision mixer, a hardware keyer or a second facility, you need a video signal instead: SDI key and fill, or NDI with an alpha channel. NDI graphics →
Frame-accurate playout is the other limit. A browser renders when it renders; for streaming that is invisible, but a broadcast chain that counts frames will want a real playout server.
Why we build this way
The output page in LowerThird Software is deliberately boring HTML5: transparent background, CSS animations, state over SignalR. It means your encoder does the compositing on hardware it is already using, and a designer who knows CSS can change the look without a rebuild. See it running in OBS →
HTML5 graphics, ready-made Templates, panel and transparent output in one install — no template project to start from scratch.
Get early access