To filter words from livestream alerts, configure the alert provider that creates the alert, not necessarily the streaming app that displays it. In Streamlabs, you can use its standard profanity list, add custom bad words, or use both; depending on the setting, a match may filter text or suppress the whole alert.
That distinction matters if OBS, YouTube Studio, or another app is part of your setup. A chat filter and an alert filter affect different things, and not every provider offers the same controls. This guide uses Streamlabs as the documented alert example and explains how to test the result without assuming every matching event will still appear.
Where alert word filtering lives
An on-screen alert usually comes from a provider or widget, then appears inside the software you use to compose your stream. If you add a Streamlabs alert as a browser overlay in OBS, OBS displays the overlay; it does not become the service that decides which words the alert contains. The relevant filter is in the provider's account settings.
OBS confirms that it does not directly provide stream alerts: third-party alert overlays are added as Browser Sources. You can read the OBS explanation of stream alerts before tracing which provider your scene uses. If you use a different alert service, look for its current documentation on word filtering rather than assuming that Streamlabs' choices and consequences apply there.
This boundary also helps when you are running a channel from a computer that stays on overnight. A continuous YouTube stream setup for a Christian radio ministry deals with the broadcast itself; alert text moderation is another part of the setup. Keep a note of the provider behind each widget so that when an alert behaves unexpectedly, you know where to investigate.
Open Streamlabs alert settings
Sign in to Streamlabs and open your account settings, then find the Alert Box or alerts area and its General Settings. Streamlabs documents the profanity filter and custom bad words in those settings. Its earlier support article describes opening Account settings and the Settings tab; the current alert setup guide also points to General Settings. Labels and navigation can move, so use the functional labels as well as the path rather than relying on an old screenshot.
The two Streamlabs references are the profanity-filter instructions and the current alert setup guide. Read the current instructions if the dashboard no longer looks like a walkthrough you have saved. Avoid changing unrelated alert settings while you are trying to test word handling; otherwise, a missing alert may have more than one possible cause.
Before editing, identify the alert types and scenes where the widget is used. A donation, membership, or other event may produce different text or use different alert settings. Make a small test plan: note the ordinary text you expect to see, a harmless custom term to check, and whether your goal is to hide only a word or to prevent an alert from appearing. Do not test with language that could affect a real viewer or public event.
Choose the standard or custom list
Streamlabs documents three choices: its standard profanity list, words you add to Custom Bad Words, or both. The built-in list is useful when you want a general filter without curating each entry. A custom list gives you control over terms specific to your channel, such as a spelling variant that has appeared in alerts. Neither choice should be treated as perfect: matching depends on the provider's behaviour, and broad terms can catch ordinary text.
For a devotional channel, for example, a short word could occur inside a name or a normal message even if you added it to stop a particular abuse pattern. In a local news loop, a place name or surname can resemble an unwanted term. Begin with narrowly chosen entries and check whether the provider supports the behaviour you need before adding ambiguous fragments. If the dashboard exposes only a broad profanity switch and not the custom controls described here, check the current provider documentation rather than searching for the same controls in OBS.
The purpose of the list is not necessarily to preserve every alert exactly as sent. A word filter may alter displayed text, while a separate option may disable alerts containing bad words. Streamlabs specifically warns that normal messages can contain a banned word and that selecting the disable-alerts behaviour may mean you receive no alert for a matching event. Decide which consequence is acceptable before enabling it; do not infer that a clean-looking overlay means the original alert still arrived.
Save and test the filter
After choosing the list and any related behaviour, save the settings before navigating away. Streamlabs' alert guide instructs users to press Save Settings. A saved dashboard setting is only the start of the check: preview or trigger a test alert through the provider, then look at the output in the same scene and overlay arrangement that you use on air.
A useful test separates three cases. First, test an ordinary alert with no listed word to confirm that it still appears. Then test a controlled sample containing one custom term, using a private or provider test function if available. Finally, test an ambiguous ordinary word only if you can do so without sending a real alert to viewers. Record whether the text changed, the alert was withheld, or nothing happened. That observation is more useful than assuming all filters censor text in the same way.
If an alert vanishes, check the provider's alert history or Recent Events as well as the on-screen overlay. Then inspect whether the filter is set to disable matching alerts, whether the event type was enabled, and whether the correct widget is in the scene. This avoids “fixing” the word list when the real issue is a disabled alert or an overlay pointing at a different account. For an unattended channel, test after any meaningful change, rather than waiting for an overnight event to reveal that a setting had side effects.
Check Recent Events behaviour
Streamlabs documents an option to apply its profanity settings to Recent Events. That means the control can affect the dashboard's event list in addition to the on-screen alert. If you rely on Recent Events to check what happened while you were away, decide whether you want matching text filtered there too. A setting that improves what appears on screen can also change what you see when reviewing activity later.
The dashboard and the live overlay are different places to inspect. A test alert that looks clean in the scene does not by itself show what Recent Events will display, and a filtered Recent Events entry does not establish that a live alert was displayed. After enabling the option, use a test event and inspect both views. If the history is important for moderation or troubleshooting, note what the provider retains and what its current documentation says; do not rely on a filtered display as the sole record of what a viewer submitted.
This is particularly relevant when a small team shares channel duties. Someone reviewing the alert feed in the morning may need to know that a matching item was hidden or suppressed, rather than concluding that no event occurred. Agree on a simple handover note: which filter is active, whether Recent Events is included, and where a moderator can check the provider's event records. The exact record-keeping options depend on the provider, so verify them in its current help pages.
Separate alert filters from chat moderation
A word filter for alerts does not automatically moderate the source chat. YouTube's blocked words feature applies to live-chat messages; YouTube explains that messages containing or closely matching listed terms may be held for review. It is a separate control from a third-party alert overlay. See YouTube's live chat moderation guidance for the current description of blocked words and review settings.
The reverse is also true: blocking a term in YouTube chat does not establish that an alert provider will filter text it receives or displays. If your concern is abusive chat, set the platform's chat moderation controls and review messages according to the current YouTube options. If your concern is names or text appearing in an alert, configure the alert provider. You may need both, but one should not be described as a replacement for the other.
Streamlabs also documents Cloudbot Word Protection as a chat tool, distinct from the alert profanity filter. Its Cloudbot moderation guide is relevant when your goal is restricting words in chat, not when you are trying to control the alert overlay's rendered text. Keeping these controls separate prevents a common troubleshooting dead end: you add a chat blacklist, but the alert still displays the same text because the overlay has its own settings.
| Control | What it affects | Possible result |
|---|---|---|
| Streamlabs profanity and custom-word settings | Streamlabs alerts, and Recent Events if that option is enabled | Matching text may be filtered; disabling matching alerts can withhold the alert |
| YouTube blocked words | YouTube live-chat messages | Matching messages may be held for review under YouTube's moderation behaviour |
| Streamlabs Cloudbot Word Protection | Chat moderation through Cloudbot | Restricts words in chat, rather than setting alert-overlay text behaviour |
| OBS Browser Source | Displays a third-party overlay in the scene | Does not itself provide the alert provider's word list |
The table describes only the documented boundaries, not a promise that every provider handles a match the same way. Check the service that actually supplies each feature.
Avoid unintended matches or suppressed alerts
A filter is useful only if its cost is acceptable. Streamlabs warns against banning words that could be part of a normal message. A short term might appear within a viewer's name, a place, or an ordinary sentence. If you choose an option that disables alerts containing bad words, a matching event may not be shown at all. In that case, you may miss the event rather than receive a censored version of it.
For a small channel, a cautious process is easier to maintain than a long list nobody remembers. Add a term only after you have seen a problem it addresses. Prefer a distinctive full word over a fragment when the provider's matching rules allow it. Test spelling and case behaviour using the provider's own test tools, and keep a note of why each custom term was added. If an ordinary alert is affected, remove or narrow the entry and test again.
When a harmful message is a concern but automatic filtering is too blunt, Streamlabs also describes alert moderation, where alerts can be approved before appearing. That is a human review step, not another name for word filtering. It takes attention and can delay display, but it may suit a channel where context matters more than immediate automatic handling. Check the current provider settings and decide who is responsible for reviewing pending alerts; an unattended channel cannot assume a moderator will always be available.
A 24/7 bhajan stream's upload-speed requirements are a separate reliability question, but the same practical habit applies: test the complete path you will actually use. For alert filtering, test from provider settings through the overlay and, if enabled, Recent Events. If you run a recorded-video channel such as a continuous lecture stream, keep alert moderation in the channel operations checklist rather than assuming the video loop controls viewer-generated alert text.
Before changing a live setup, note the current setting so you can restore it if needed. Keep one test alert that should pass, and, where safe, one that demonstrates the intended match consequence. Ask a second person to review the result if a suppressed alert would have operational consequences. Those simple checks do not guarantee that every edge case is caught, but they reduce the chance that a broad term quietly hides routine events.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does OBS have a built-in filter for alert words?
OBS displays third-party alert overlays as Browser Sources and does not directly provide stream alerts. Configure word handling with the alert provider that supplies the overlay, then check the result in OBS. If your provider is not Streamlabs, consult its current documentation rather than assuming its settings match Streamlabs.
Will filtering a bad word keep the rest of the alert on screen?
Not necessarily. The outcome depends on the provider's settings: text may be filtered, or an option to disable alerts containing listed words may suppress the whole alert. Test the behaviour you have selected and do not assume a matching event will remain visible.
Does YouTube's blocked-word list filter alert overlays?
YouTube's blocked words feature is for live-chat messages, not a general control over third-party alert overlays. Use it for chat moderation and the alert provider's controls for alert text. A channel may need both settings for different purposes.
What if I want to check a questionable alert before it appears?
Look for an alert moderation or approval feature in your provider. Streamlabs documents moderation as a way to approve alerts before display; it is distinct from an automatic word filter and requires someone to review them. Check the current settings to understand how pending alerts are handled.