OBS Browser Source QA Checklist for Paid Alerts

Paid alerts should be tested like production inputs

An OBS browser source is not just decoration. OBS describes Browser Source as a browser inside OBS that can run custom layout, image, video, and audio tasks. For paid TTS, Upload Corner, tips, and alerts, that browser source is a revenue surface. If it breaks, the viewer paid for a moment that the stream did not deliver cleanly.

Most alert problems are predictable. The source is the wrong size. Audio is not controlled through OBS. Long names overflow. A scene transition hides the alert. A cached page does not refresh. A moderator approves a message but cannot pause it. The streamer discovers the problem only after a viewer pays.

QA prevents that. It does not need to be complicated. It needs to happen in the actual scene collection, with real test events, before the stream announces paid features.

• Test in the real scene, not only a blank scene.
• Test with the same resolution and canvas used for the stream.
• Test audio through the same monitoring path the streamer uses live.
• Test moderation actions, not only successful playback.
• Record the test and watch it back.

Size, crop, and safe areas

Start with layout. Set the browser source to the expected canvas size or widget size. If the alert is supposed to be full-width, make sure it scales cleanly at 1920x1080 and any vertical or cropped output you use. If it is a corner alert, make sure it does not cover health bars, captions, chat, sponsor labels, faces, or important game UI.

Use extreme test data. Long usernames, wide images, multiline messages, emojis, numbers, and mixed case text reveal layout problems faster than a perfect test name. If Upload Corner accepts images, test portrait, landscape, transparent, dark, light, and tiny images.

The goal is not to make every possible submission beautiful. The goal is to make bad inputs fail gracefully and good inputs look intentional.

• Check desktop 16:9 output.
• Check vertical or clipped output if you use one.
• Check game scenes, Just Chatting scenes, IRL scenes, and sponsor scenes.
• Check the longest allowed TTS message.
• Check the largest allowed upload crop.
• Check whether text remains readable on a phone screen.

Audio deserves its own pass

Paid TTS can be visually perfect and still fail because nobody hears it, or because it doubles, clips, routes to the wrong track, or plays over a serious segment. Do a dedicated audio pass before enabling purchases.

Check whether the browser source uses OBS audio control if your workflow needs it. Check stream mix, monitor mix, recording track, and VOD track if your setup separates them. Play a quiet voice, loud voice, fast voice, and long message. Then play the same alert while music, game audio, and microphone are active.

Set rules for priority. Paid TTS should not drown out emergency instructions, sponsor reads, safety moments, or guest audio. A pause or ducking workflow is better than relying on the streamer to mute everything manually.

• Confirm viewers can hear the alert.
• Confirm the streamer or producer can monitor it if needed.
• Confirm it does not double through desktop audio and browser audio.
• Confirm it respects any VOD track policy.
• Confirm moderators can pause or skip audio.
• Confirm failed audio creates a retry path, not a silent paid event.

Queue state testing

Viewer anxiety comes from unclear state. A paid moment can be submitted, paid, pending, approved, playing, rejected, skipped, failed, or refunded. If the overlay only handles the playing state, the rest of the workflow feels unreliable.

Run test events through every state. Approve one. Reject one. Let one fail if your tool supports test failure. Pause the queue. Resume it. Skip one. Replay one. Then check what the viewer, moderator, streamer, and OBS output each see.

StreamableBot's value is strongest when moderators can control paid moments without making the streamer stop. QA should prove that control path, not just the animation.

• Buyer confirmation is clear.
• Pending review is clear.
• Moderator approval is fast enough.
• Rejection reason is understandable.
• Pause state prevents new surprises.
• Replay and skip controls work.
• Logs show enough detail for support after the stream.

Scene transition and refresh checks

Alerts rarely live in one scene forever. Streamers switch from gameplay to Just Chatting, desktop to IRL, intro to main, sponsor segment to normal mode, and BRB to live. The browser source must survive those transitions or be duplicated deliberately.

Test an alert while changing scenes. Test it when the source is hidden and shown again. Test after refreshing the browser source. Test after restarting OBS or opening Remote OBS if that is part of the production. StreamElements and Streamlabs support docs both emphasize browser-source setup and troubleshooting because small source mistakes are common.

Do not rely on memory. Save a QA checklist in the stream runbook. The boring checklist is what protects the paid feature when you rebuild scenes later.

• Alert plays while switching from intro to main.
• Alert source appears in every scene where it should appear.
• Hidden scenes do not create surprise audio.
• Refresh does not lose queue state unexpectedly.
• OBS restart has a known recovery path.
• Remote producer can refresh or hide the source if needed.

Security and privacy checks

Browser-source URLs can be powerful. Treat overlay URLs, moderator pages, and paid queue links like production controls. Do not show them on stream. Do not paste them into public chat. Do not include them in screenshots unless the secret parts are removed.

Also test the content itself for privacy. Upload Corner can show faces, addresses, documents, screenshots, maps, usernames, or private messages if rules are loose. Paid TTS can read private information aloud. Alerts can reveal payment names if the display format is careless.

The QA checklist should include privacy inputs, not only funny ones. Try a phone number, an address-like string, an oversized username, and a file that should be rejected. Moderators need to see those cases before the first real viewer submits one.

• Hide browser-source URLs from public scenes.
• Use separate moderator and display links when available.
• Reject uploads with private information.
• Do not display payment details beyond what the viewer expects.
• Rotate exposed URLs or tokens after accidental leaks.
• Audit tutorial screenshots before posting them.

A 15-minute preflight

Before a stream with paid alerts, run a short preflight. It should be fast enough that you will actually do it. The point is to catch obvious failures before viewers pay.

Open OBS, open the moderation queue, start a local recording, and send test events: short TTS, long TTS, rejected TTS, image upload, rejected image, small tip, large tip, queue pause, and scene switch. Watch the recording for readability and audio.

If any event fails, fix it before announcing the feature. Do not promise chat that paid moments are open while the source is still untested.

• Short TTS plays correctly.
• Long TTS wraps or truncates correctly.
• Rejected TTS never reaches OBS.
• Approved image appears at the right crop.
• Rejected image stays out of OBS.
• Tip alert is audible and readable.
• Pause button works.
• Scene switch does not break playback.
• Recording confirms the viewer experience.

Check the public output, not only OBS

OBS can look correct while the public platform output still has problems. Audio may be missing from a VOD track. A vertical crop may cut off the alert. A browser source may be readable in the preview but too small on a phone. A platform delay may make queue timing feel stranger than it does in the control room.

Send at least one private, unlisted, or low-risk test to the same destination path you will use live. Watch the public Twitch, Kick, or YouTube page on a phone and a desktop. If the paid moment matters enough to charge for it, it matters enough to test where viewers actually see it.

• Watch one test from the public page.
• Check a phone screen in portrait and landscape.
• Check the recording or VOD audio track.
• Check whether alert text survives compression and scaling.
• Check whether platform delay changes the queue explanation viewers need.

Other resources

Use these references when checking browser-source behavior, alert setup, and overlay troubleshooting before paid stream moments go live.

• OBS Studio: Browser Source.
• OBS Studio: alerts and chat box tutorial.
• StreamElements: adding and troubleshooting overlays.
• Streamlabs: Alert Box browser-source setup.
• Sound Alerts: Browser Source setup.