A reliable way to customise stream alerts with CSS and JavaScript is to start with a StreamElements AlertBox, enable custom code for the event type, and edit its HTML, CSS and JavaScript in the overlay editor. Use the AlertBox’s documented template variables for event details, then test the result in the scene where it will appear.
CSS shapes and animates the alert; HTML provides its content structure; JavaScript can coordinate behaviour in response to widget events. These controls are specific to the platform and widget you choose, so decide first whether a native AlertBox or a more flexible Custom Widget fits the job.
Choose AlertBox or Custom Widget
An AlertBox is the direct route when you want to restyle common events such as follows, subscriptions or tips. It is a native overlay widget designed to display events from a queue. You can configure the alert for a particular event type and customise its markup, styling and behaviour without building a general event-handling widget from scratch. StreamElements explains its overlay options in the official overlays guide.
A Custom Widget is useful when the alert is part of a larger bespoke display, or when you need behaviour that does not fit the AlertBox’s event-specific template. Its editor provides HTML, CSS, JavaScript and configurable fields. You can respond to widget-load and event-received events, but this flexibility comes with more responsibility: you must understand the event data and build the display behaviour yourself. StreamElements documents a protected sandbox with limitations, including no access to cookies, console.* or IndexedDB storage. A Custom Widget does not escape those restrictions.
| Route | Good fit | What you control | Main trade-off |
|---|---|---|---|
| AlertBox custom code | Restyling an alert for a known event type | Event-specific HTML, CSS and JavaScript | Variables and settings depend on that alert type |
| Custom Widget | A bespoke panel or coordinated widget behaviour | HTML, CSS, JavaScript and configurable fields | More code and event handling to maintain within a protected sandbox |
| Streamlabs Alert Box | Setting up alerts through Streamlabs’ own workflow | Its alert settings, browser source and theme choices | A different platform workflow; do not assume its controls match StreamElements |
If you want a preset-led setup rather than writing code, Streamlabs documents its own alert configuration, tests and browser-source route. Its theme library includes free and premium choices, according to its alert setup guide. That can be a sensible route when a supplied look is enough. It is not the same as editing a StreamElements AlertBox template, and instructions for one platform should not be treated as instructions for the other.
Think about the specific change you need before choosing. Changing a typeface, spacing or entrance animation usually suits AlertBox CSS. Combining several kinds of event into a custom visual may point towards a Custom Widget. If your broadcast is part of a continuous channel, the alert is only one element of the scene; the OBS channel setup guide offers context for planning the wider broadcast layout.
Create an overlay and add AlertBox
In StreamElements, begin by creating an overlay and selecting a resolution that matches the scene you intend to use. The overlay is the canvas that contains widgets. Add an AlertBox to it, open the widget’s options, and choose the event type you plan to customise. The official getting-started guide covers creating an overlay and adding widgets; labels can change, so use the current guide if your editor looks different.
Keep the overlay canvas in mind while designing. An alert that looks balanced in a large editor preview may be too wide in a smaller browser source, or may sit behind another scene element. Decide roughly where the alert should appear and how much of the screen it may occupy before writing CSS. Leave room for long names and messages rather than designing only around a short test value.
Add only the event types you plan to use. A follower alert and a tip alert may need different wording, media or layout. Keeping their templates distinct makes it easier to reason about which variable belongs to which event and to test each one separately.
Enable custom code for an event
Open the AlertBox options, select the relevant event tab, such as Followers, and enable its custom code setting. StreamElements’ documentation describes this as enabling custom CSS for that alert type; the editor’s Code Editor provides the code areas used for the custom alert. Check the current interface labels rather than assuming every event tab has identical controls.
Treat each event as its own small component. Put the structure and text for that alert in its HTML, its appearance in CSS, and only the necessary behaviour in JavaScript. A subscriber alert may display a tier, while a tip alert may display an amount and currency. Reusing a template blindly can produce empty labels or misleading copy when a variable is not available for that event.
Start by making the smallest useful change, such as setting a readable font size and background. Save and preview before adding movement or code. If the alert disappears after a change, undo the most recent edit and check the markup, braces and selector names before changing several things at once. Small edits make errors easier to isolate.
Style and animate with CSS
CSS controls presentation: type, colour, spacing, alignment, borders, backgrounds and animation. Give your alert a clear hierarchy. For example, a name can be the largest line, a short event label smaller, and a message placed beneath it with enough width to wrap. Contrast matters more than decoration if viewers need to read the alert over changing video.
Use selectors that match the markup in your alert template. Avoid styling a broad element such as every div when a class on the alert container would be more precise. A focused selector reduces the chance that a change intended for one label also alters another part of the widget. Prefer simple declarations first, then add a transition or keyframe animation once the static layout is readable.
Animations should help viewers notice an event without keeping it on screen longer than intended. A short entrance can draw attention; an exit can return the scene to normal. Avoid a movement that shifts the alert beyond the canvas or obscures the name. Check it with long names and messages, because wrapping changes the dimensions and can expose clipping that a short preview does not show.
If you use a custom font or external asset, verify that it loads in the browser source, not merely in the editor. External dependencies add another point of failure and their availability or behaviour can change. For a basic alert, system fonts, CSS shapes and the platform’s available media variables are often easier to maintain than a stack of remote scripts and assets.
Use JavaScript for widget behaviour
JavaScript is for behaviour, not basic appearance. In an AlertBox it can coordinate actions around an event or the alert’s display duration. Keep it small: CSS is usually simpler for an entrance animation, while JavaScript is appropriate when behaviour depends on event data or timing that CSS alone does not express cleanly.
StreamElements’ AlertBox reference includes {{widgetDuration}}, a duration expressed in seconds. JavaScript’s setTimeout expects milliseconds, so convert the value before using it as a timer: multiply the duration by 1,000. This is a common source of an alert hiding too early when code treats seconds as milliseconds. Compare your code with the current custom AlertBox code reference rather than assuming a duration or event payload has a particular shape.
Use conservative DOM handling and check whether the element you intend to change exists. A typo in a selector can turn a seemingly harmless script into a no-op. Do not assume that undocumented browser features or external libraries will be available in every overlay context. If a script depends on a remote library, test after a reload and in the destination scene, and consider whether the feature is worth that extra dependency.
For a Custom Widget, the JavaScript event model is more central. StreamElements documents onWidgetLoad for information such as fields and session data, and onEventReceived for event information including a listener type and payload. Use the current widget structure documentation to understand the supported shape of those objects. The documentation warns that session-data keys may change, so avoid building an essential alert around an undocumented key. The Custom Widget tutorial and widget structure reference explain the editor tabs, fields, events and sandbox boundaries.
A Custom Widget can expose configurable values through fields, such as a label or colour that you want to adjust in the editor without editing code. That is useful for a reusable widget, but it does not mean the widget can bypass the sandbox or use any browser API without limits. If your requirement is just a differently coloured follow alert, a native AlertBox is likely easier to maintain.
Use event template variables
Template variables insert event-specific values into the alert. StreamElements documents values including {{name}} for the person associated with an event, {{amount}} where an event supports an amount, and {{tier}} for a subscription tier. {{sender}} can identify the sender of a gifted subscription; {{currency}} is relevant to tips. The available values depend on the event type, so consult the reference before using one.
Message and media variables require particular care. {{message}} and {{messageRaw}} represent user messages, while {{image}}, {{video}} and {{audio}} are media URLs. Use the variable appropriate to the content you intend to show; do not label an amount or message as if it were present for every event. Test special characters and long text to see how your layout responds. The platform reference describes the available variables and examples, but you should not infer a sanitisation guarantee from the existence of a template variable.
A simple template might use the name on one line and a short event phrase below it. If the event supports an amount, include that value only in its relevant event template. Keep wording clear when a field may be blank, and do not make the alert depend on a value that your test event does not provide. This is also why event-specific markup and selectors are often more dependable than trying to make one elaborate template cover every alert.
Test alerts and add the browser source
Previewing inside an overlay editor is useful, but it is not the end-to-end check. Trigger representative events, inspect each event type you have customised, and then load the overlay as a browser source in the actual streaming software scene. Confirm that the alert is visible, positioned correctly, readable at the scene’s dimensions and not covered by another source. Streamlabs’ setup guide describes its own test controls and browser-source addition; use the relevant platform’s current instructions for the workflow you selected.
Test more than the ideal case. Try a long username, a message with punctuation, a media event if you use media, and an alert arriving while another one is visible. Check that the queue behaves as expected and that an exit animation does not cut off text. If a value is missing, first verify the event type and variable name against the documentation; changing CSS will not fix a template variable that the event does not provide.
Keep an eye on the browser source after changes. Save the overlay, refresh the source if it still shows an old version, then test again. If you run a 24/7 channel, an alert is a small part of a scene that needs to remain legible and predictable over long sessions; the watch-time guide for Indian channels discusses planning the viewing experience beyond a single overlay.
If you prefer to avoid leaving a personal computer running for a continuous broadcast, StreamNeo removes that particular burden: you upload the video and connect your YouTube stream key, then the channel can run while your computer is off. It is YouTube-only and does not replace an overlay editor or change how alert code works. The cloud streaming options guide can help you think through the separate question of where a continuous broadcast runs.
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
Can I add JavaScript to a StreamElements AlertBox?
Yes, the AlertBox custom-code path includes JavaScript as well as HTML and CSS. Enable custom code for the relevant event type and use the documented variables and behaviour for that alert. Keep the script focused and test it in the browser source used by your scene.
Should I use an AlertBox or a Custom Widget?
Use an AlertBox when you are customising a standard event alert and its event-specific template fits. Choose a Custom Widget when you need a more bespoke component or behaviour and are prepared to handle its fields and event data. Both have platform constraints; a Custom Widget runs in a protected sandbox, not outside it.
Why does my alert look different in the editor and OBS?
The editor preview and the browser source may differ in dimensions, refresh state or scene placement. Check the source canvas size, refresh the browser source after saving, and inspect long text and animation in the actual scene. Confirm that no other source covers the alert.
Can I use these instructions for Streamlabs?
Not as a direct, identical workflow. Streamlabs has its own alert settings, testing and browser-source steps, and its own theme choices. Follow its current documentation for those controls; the concepts of checking readability and testing in the destination scene still apply.