Browser Source Layout for Paid Alerts on Desktop and Mobile Streams

Paid alerts have to earn their screen space

A paid alert is more expensive than a normal overlay because it uses attention the streamer could spend on the game, camera, chat, or guest. If it covers the action, runs too long, or cannot be read on mobile, viewers learn to ignore the very moment they paid for.

The layout should answer three questions quickly: who triggered it, what happened, and what should the streamer react to. Everything else is optional. The more chaotic the stream, the more disciplined the alert needs to be.

This matters for Streamable Bots because paid TTS, tips, uploads, and special browser-source moments often share the same canvas. If the layout system is weak, each new monetization feature makes the stream messier.

Start with the OBS source, not the animation

OBS Browser Source documentation describes fixed width and height, custom CSS, frame rate, refresh behavior, shutdown behavior, and page permissions. Those settings shape how your alert actually behaves inside the scene.

Before designing any animation, decide the source dimensions and where the browser source will live. A 1920 by 1080 overlay can still be used carefully, but the visible alert should occupy a defined safe area. A corner alert should not become a full-screen takeover because a username is long.

Use a test scene that matches the real stream. A layout that looks clean on an empty canvas may cover subtitles, facecam, minimap, chat, sponsor graphics, or vertical crop content once the real scene is active.

• Set a fixed browser-source width and height.
• Use custom CSS to keep transparency, margins, and overflow predictable.
• Test refresh behavior before relying on scene changes.
• Avoid source resizing when usernames, amounts, or messages are long.
• Keep an emergency hide control for the producer or moderator.

Design safe zones for three viewing contexts

Most streamers design for their OBS monitor, but viewers may watch on a phone, a vertical restream, a small embedded player, or a living-room TV. Paid alerts need to survive all three common contexts: desktop 16:9, mobile 16:9, and vertical crop or vertical output.

Do not put essential text at the far edges. Do not make the amount or message so small that it disappears on mobile. If you stream horizontally and vertically, design the paid moment so the important part can appear inside a central safe column or use separate layouts.

A practical rule: the alert can be decorative outside the safe zone, but the viewer name, reward type, and message summary should remain readable inside it.

• Desktop 16:9: avoid covering facecam, gameplay HUD, and captions.
• Mobile 16:9: use larger text and fewer words.
• Vertical output: keep the paid moment in a central column or create a dedicated vertical overlay.
• IRL camera: avoid bottom edges where movement and hands often appear.
• Chat-heavy streams: keep alerts away from the chat overlay unless the two are intentionally connected.

Use hierarchy instead of loudness

A paid alert does not need to be huge to feel valuable. It needs a clear hierarchy. The viewer name can be prominent, the reward type can be a compact label, and the message can be short enough for the streamer to read while doing something else.

Avoid making every element fight for first place. If the voice is the main moment, keep the visual alert calmer. If the image upload is the main moment, keep the text short. If the tip amount is the main moment, do not bury it under effects.

Good hierarchy also helps moderators. They can glance at the overlay and know which queue item is currently playing.

• Primary: viewer name or paid moment type.
• Secondary: short message, voice, or uploaded image.
• Tertiary: amount, icon, queue label, or decorative motion.
• Never primary: long disclaimers, repeated branding, or tiny instructions.

Control motion and duration

Motion should help the streamer notice the moment, then get out of the way. Long animations feel impressive the first time and exhausting the tenth time. Paid alerts should have different motion budgets based on their interruption level.

A quick TTS alert can slide in, show who paid, and leave. A premium upload may deserve more time. A full-screen takeover should be rare and strongly priced because it blocks content for everyone.

Test the alert while the streamer is speaking. If the animation, audio, and streamer voice all compete, reduce one of them. Paid moments should create reactions, not force the streamer to fight the production.

• Quick alert: 3 to 6 seconds of visual attention.
• TTS alert: visual can leave while audio finishes if the queue state remains clear.
• Upload alert: match duration to readability and image value.
• Premium takeover: rare, explicit, and easy for mods to stop.
• Repeated alerts: use calmer motion after the first few in a burst.

Handle long names and bad inputs

Viewers will use long names, unusual casing, emoji, repeated characters, and messages that are funny only because they break layouts. Your overlay should treat those as normal inputs, not emergencies.

Use truncation, wrapping, max lines, and fallback styles. A paid alert should never push the browser source larger, cover the whole screen, or make the rest of the page scroll because one username is enormous.

The same applies to uploaded images. Contain or crop predictably. Do not stretch a tall image into a wide frame or let a transparent PNG become unreadable over bright gameplay.

• Set maximum name length.
• Limit message lines and show a queue details view for moderators.
• Use readable fallbacks for emoji or unsupported characters.
• Test light and dark scenes.
• Use image containment rules for viewer uploads.

Keep the alert readable without audio

Some viewers watch muted, and some platforms autoplay muted previews. If the paid alert only makes sense with sound, part of the audience will miss the moment. Add a short visual summary for TTS, tips, and uploads without turning the overlay into a transcript wall.

For TTS, show the first useful phrase or a short label like voice message from username. For uploads, show the reward type and viewer name. For tips, show the thank-you and amount only if that matches the streamer's privacy and culture.

Make mod controls invisible to viewers

Moderators need control, but viewers do not need to see the machinery. Keep approval buttons, queue status, rejection reasons, and support notes in the dashboard, not the public overlay.

The public overlay should show only the state that affects the viewer: queued, playing, paused, or temporarily disabled if necessary. Too much internal status makes the stream look broken even when the team is operating correctly.

This separation also protects privacy. Browser-source URLs, queue IDs, internal notes, payment IDs, and moderator names should not appear in OBS.

• Public: viewer name, moment type, safe message, and simple status.
• Private: approval buttons, payment status, rejection notes, and queue controls.
• Producer-only: emergency hide, pause queue, replay, skip, and source refresh.
• Never public: secret URLs, stream keys, payment IDs, or support notes.

A practical layout recipe

Start with one alert family instead of separate designs for every feature. Use the same safe area, typography, timing, and status language for TTS, tips, uploads, and special effects. Then vary color, icon, and small motion details by reward type.

This makes the stream easier to understand. Viewers learn the visual language once, and moderators can spot problems faster. It also makes future paid features less likely to clutter the scene.

• Create a compact lower-third for quick paid moments.
• Create a larger side panel for viewer uploads.
• Create a rare full-screen template for premium takeovers.
• Use one queue status style across all paid rewards.
• Use one emergency hidden state across all paid browser sources.
• Test all templates in gameplay, IRL camera, desktop, and vertical layouts.

Other resources

Check these references when designing browser-source layouts and moderation workflows across Twitch, Kick, and YouTube.

• OBS Studio: Browser Source documentation.
• Twitch Developers: Chat and Chatbots.
• Kick Dev Docs: Chat API.
• YouTube Help: Moderate live chat.