A 24/7 YouTube radio stream can show a current track and upcoming requests by placing a queue overlay in the scene your encoder sends to YouTube. In OBS, a common route is to add the request system’s overlay URL as a Browser Source and position it over the video.
The overlay does not create a request system or connect itself to YouTube chat. Your chosen system must supply the queue and keep it current; test that connection, track changes and moderation before relying on it overnight.
Decide what the overlay should display
Start with the information a listener needs, not with a particular widget. A small devotional channel might show the current bhajan and the next few approved requests. A lofi station may prefer a discreet current-track label so the queue does not compete with the artwork. A local news loop might show requests only during a music segment, or not at all.
Separate “now playing” from “up next” in your requirements. Some overlays display only the current song, while others can show a queue, artwork, requester names, progress or a queue count. These are possible features, not guarantees: check the exact overlay and the data it receives. A third-party OBS resource, for example, describes current-track and upcoming-queue display options, but its listed context is Twitch and does not establish compatibility with YouTube chat. The resource description is useful as an illustration of overlay controls, not as a recommendation for a YouTube setup.
Choose the display with readability in mind. A long list of song titles can become hard to read on a phone, where many viewers watch live video. Consider limiting the display to the current item and a few upcoming requests, or rotating through entries if the system supports that. Avoid making the queue so prominent that it obscures lyrics, a deity image, a presenter or other essential content.
Requester names raise a separate moderation and privacy question. Decide whether names are useful to your audience and whether you want them visible before requests are approved. If a request page lets people enter arbitrary text, check how the overlay renders it and whether moderators can reject inappropriate entries. Do not assume that a visual option to show requesters means the request system has suitable controls.
Write down what “working” means before configuring OBS: a request enters the chosen queue, a moderator can approve or remove it, playback changes when expected, and the displayed queue catches up. If you only need to show the current track, define that narrower test. A clear target makes a blank or stale overlay easier to diagnose.
Choose a request system and queue feed
First decide where requests will come from. They might arrive through YouTube chat, a separate submission page, or a moderator who enters requests into a queue. The request input and the display feed are related but distinct: an overlay can read a queue without accepting YouTube chat, and a chat-based workflow does not automatically mean it provides a browser-source overlay.
Check the documentation for the exact combination you intend to use. Confirm whether the system supports your request route, what playback arrangement it expects, whether it exposes a browser-source URL, and how it handles approvals, skips, removals and duplicates. If documentation does not clearly say that YouTube chat is supported, do not promise that it is. You can use a separate page or moderator entry instead, provided that is practical for your channel and explained to viewers.
The queue needs a dependable source of truth. If a player or request page must remain open for playback or processing, closing it may stop the workflow even though OBS continues to show the last rendered overlay. A third-party community listing for a Nightbot song-request dock says its AutoDJ page must stay open for queue processing and playback. That is a tool-specific listing, not official Nightbot guidance or proof of YouTube compatibility; check the listing and current documentation before building around it.
Some tools offer a widget URL intended for OBS; others may need a separate page, integration or custom overlay that reads queue data. StreamElements documents a Media Request widget and OBS.Live browser-source workflow, but its guide alone is not evidence that every configuration supports your YouTube request path. Review the current StreamElements guide and verify your specific workflow rather than inferring chat support from the presence of a widget.
Compare systems on the job they actually do:
| What to check | Questions to answer before choosing |
|---|---|
| Request input | Is it YouTube chat, a separate form, or moderator entry? Is your channel’s exact workflow documented? |
| Queue display | Does it show current track, upcoming items, artwork, requester names or progress? Which of these can you turn off? |
| Playback dependency | Must a player, browser tab or another application stay open for requests and queue processing? |
| Moderation | Can you approve, skip, remove or prevent duplicates? Who can use those controls during a long broadcast? |
| Overlay feed | Is there a Browser Source URL, and does it update as the underlying queue changes? |
| Operations | Will playback and the overlay remain available if your local computer or browser closes? |
No row should be treated as a universal feature list. Confirm the details with the vendor or project that supplies your chosen system. A system can be suitable even if it does not accept requests directly from YouTube chat; it just needs a request path your moderators and viewers can use reliably.
Add its URL as an OBS Browser Source
Once you have a working queue feed, obtain the overlay URL from its current settings or documentation. Treat it as a display address, not as proof that the overlay receives requests or controls playback. If the system asks you to customise layout, theme or displayed fields before generating the URL, save those choices and copy the resulting address carefully.
In OBS, select the scene used for your radio broadcast and add a Browser Source. Give it a descriptive name, such as “Track queue”, so it is easy to identify later. Enter the queue-overlay URL in the source properties. The source is a web view rendered into the scene; YouTube receives the finished scene from your encoder, not a separate connection from the overlay.
Use the size controls and any options the overlay itself provides to choose what appears. Some widgets expose settings for item count, cover art, progress, requester name, theme, width, scale or opacity; availability varies by tool. If a URL includes a private token or session value, do not publish it in a screenshot or public support post. Anyone with access to a private feed may be able to view its contents.
Check that the Browser Source actually renders before moving on. A blank panel could mean the URL is wrong, the service requires a sign-in, the feed is unavailable, or the widget has not been configured. Test the address and settings using the tool’s guidance rather than assuming an OBS problem. If the source renders locally but its contents do not change after a queue action, troubleshoot the feed or request workflow as well as the scene.
For a first pass, keep the scene simple: the radio visual, the audio source and the queue. That makes it easier to determine whether text is clipped, whether the wrong item is shown and whether a change in playback reaches the overlay. Add decorative elements after the queue behaves as intended.
Size and position the overlay
The Browser Source’s dimensions define the area available to its page, while the overlay’s own layout and scale settings may affect how content fits inside it. Start with a size that matches the actual broadcast canvas, then adjust using OBS’s preview. A widget with a fixed layout can crop or leave unused space if the source dimensions do not suit it.
Place the queue where it does not cover the most important part of the video. For a full-screen album image, a narrow panel along one edge may work; for a meditation scene with a central subject, a corner may be less distracting. Check the whole scene at the size viewers will see it, rather than judging only the OBS preview at full desktop scale. Small text that looks clear on your monitor may be unreadable in a phone view.
Use the source transform handles or properties to resize and position it, and lock the source once it is in place if that helps prevent accidental movement. Keep a little breathing room from the edges, since text or decorative outlines at the boundary can feel cramped or be cut off by the player presentation. If the overlay has opacity controls, compare readability against the background rather than making it transparent by default.
Test longer titles and unusual characters, not just a short sample track. A title that wraps across several lines can push the next items out of view. If you cannot control wrapping, reduce the number of visible items or place the queue over a plain, stable part of the scene. Do not shrink all text until it is technically present but difficult to read.
Finally, check that the source is present in the scene actually used for streaming. OBS scenes can have similar names, and an overlay added to a test scene will not appear if the encoder sends another one. A private rehearsal is a useful way to confirm the broadcast composition without relying solely on the local preview; see this guide to testing a 24/7 stream privately.
Connect the encoder to YouTube Live
The queue overlay is part of the video composition. Connecting OBS to YouTube is a separate step: in YouTube Studio’s Live Control Room, create or select a stream, then use the server URL and stream key provided for the encoder. YouTube’s instructions for creating a live stream with an encoder describe the setup. Interface labels can change, so follow the current instructions shown in your account.
In OBS, enter the connection details in the appropriate streaming settings, or use the connection method YouTube currently offers for your encoder. Keep the stream key private: it grants the ability to send a broadcast to the channel. Do not put it in a public overlay URL, a screen recording or an open support post. If you think it has been exposed, replace it using the controls in YouTube Studio and update the encoder.
Before making a public broadcast, check that the Live Control Room preview shows the intended scene and that audio is reaching YouTube. The preview is also a chance to notice a missing overlay, a wrong scene or a queue panel placed over important content. If your channel is new to this workflow, follow the private test procedure from start to finish, including the request route and track changes. The separate guide on testing a YouTube loop stream privately can help structure that rehearsal.
Do not treat a visible queue as evidence that every other part of the stream is ready. Confirm audio levels, the intended privacy setting, the correct channel, and the playback source. Keep the stream key separate from the queue URL and avoid sharing either one unnecessarily; they serve different purposes and can expose different kinds of access.
Check queue updates and track changes
A static overlay can look correct while being operationally useless. Test the whole chain: submit a request through the real input route, check that it arrives in the queue, approve or remove it as planned, confirm the player’s behaviour, and watch the overlay after the queue changes. Repeat when a track ends or is skipped. This establishes whether the system supplies fresh data and whether the Browser Source reflects it.
There is no universal refresh behaviour. Some overlays may update automatically; others may need a page refresh, a setting, or a continuously open companion page. Do not assume that a Browser Source refreshes just because OBS is displaying it. Look for an explicit refresh interval or update description in the chosen system’s current documentation, then verify what happens in your setup. If a manual refresh is necessary, consider who will perform it and what the stream displays while that person is away.
Run a practical failure check before relying on the setup: leave the scene open long enough to see a track change, briefly interrupt the overlay feed if the system allows a safe test, and confirm what viewers would see. A stale queue should be recognisable as stale, not mistaken for current information. You might hide upcoming requests when the feed is unavailable, or use a simple fallback label, if your overlay supports it.
Also test moderation from the account and device you expect to use. A queue may accept requests but make it awkward to reject unsuitable entries during a broadcast. Decide who monitors submissions, what happens when no moderator is present, and whether requests are paused outside staffed hours. Do not leave an unmoderated submission surface open simply because the stream itself runs continuously.
Keep a short operating note with the overlay URL location, the scene name, the request-system login or owner, and the recovery steps. Store credentials securely rather than in a public document. If the overlay breaks, the note can help a trusted moderator distinguish a scene problem from a queue-feed problem without changing the stream key or unrelated settings.
Plan for an always-on stream
A 24/7 schedule changes the operational question. You need to know what happens when the computer, browser, player, request service or network connection is interrupted. If your setup depends on a local player being open, someone must account for that dependency; an OBS Browser Source does not keep the request system alive by itself. If the encoder stops, the queue may continue in one place while YouTube receives no broadcast, or the reverse. Map which components need attention and who can act when you are not at the desk.
If maintaining a local encoder and its surrounding workflow is the main pain, StreamNeo can remove the need to keep your own computer running for the broadcast: you upload a video and provide your YouTube stream key, while the stream is monitored and restarted if it drops. It is YouTube-only, and it does not make the queue feed or request system compatible automatically, so you still need to verify how your displayed queue is supplied and refreshed.
Plan for a failure without assuming a promised uptime. Test the recovery path: who notices a missing stream, how they check the Live Control Room, and which parts they restart or reconnect. A guide to restarting a YouTube radio stream after a disconnect is relevant if you operate the encoder yourself. Keep a copy of the source file and configuration notes so a recovery does not depend on reconstructing the scene from memory.
Think about recordings separately from the live broadcast. YouTube says streams under 12 hours can be automatically archived, while streams longer than 12 hours may not be captured at all; it recommends making a local archive if you need a complete recording. See the current YouTube archive guidance. A continuous channel should not promise viewers a complete replay simply because the live feed remains up.
DVR is also not a substitute for a queue or a dependable archive. YouTube explains that DVR allows viewers to pause and rewind, but rewind can be limited on very long streams and may be unavailable beyond 12 hours. Check the current DVR guidance and tell viewers what replay behaviour to expect if that matters to them.
Music rights remain your responsibility regardless of whether requests are moderated or displayed neatly. YouTube’s live-stream terms say creators must have the rights needed for live content, including music licensing rights. YouTube also scans live streams for third-party content; a match can interrupt or terminate a stream, and licensed content may still require the rights owner to allowlist the channel. Review the current copyright guidance for live streams and make sure the music you play is cleared for this use.
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 OBS display the current song and upcoming requests?
Yes, OBS can display a queue overlay as a Browser Source in the scene sent to YouTube. Whether it shows only the current track or also upcoming requests depends on the overlay and the queue data supplied to it. Test both the visual layout and the update behaviour.
Does adding a Browser Source connect requests to YouTube chat?
No. A Browser Source displays a page; it does not, by itself, accept chat requests or connect them to a player. Confirm that your chosen request system supports the input route you want and feeds the overlay with current queue information.
Will a 24/7 YouTube live stream save as a complete replay?
Do not rely on that. YouTube says streams longer than 12 hours may not be captured at all, and DVR rewind can also be limited or unavailable for very long streams. If a complete archive matters, keep a separate local recording and check YouTube’s current guidance.
What should I check if the queue stops changing?
Check the request system first: confirm that a test request reaches its queue and that playback or the queue processor is still running. Then check whether the overlay feed updates on its own or requires a documented refresh, and confirm OBS is showing the intended Browser Source. A visible but stale panel is not proof that the queue is connected.