Studio Queues Team · Last updated May 29, 2026
How to set up a commission queue OBS overlay using Browser Sources. What to display, how to test it, and why most artists' overlays go stale.
If you stream while you work on commissions, your viewers are watching one of two things: the art you're making, or the chat you're talking to. What they almost never see is the queue itself. Whose piece is next. How many slots are open. Where the current project is in the timeline. This information is interesting to viewers, useful to clients, and easy to display, but most commission streamers never set it up.
A commission queue overlay solves that. It's a small element that lives on your stream layout and updates automatically as your queue changes. Viewers get context for what they're watching, clients can see their place in line without bothering you, and your stream looks more professional with almost no effort once it's running.
This article walks through what a queue overlay actually is, the technical mechanism every overlay uses inside OBS, how to design one that adds value without cluttering your stream, and the structural reason most artists never build a good one.
A queue overlay is a small visual element on your stream layout that shows the state of your commission queue in real time. The simplest version displays the names (or display names) of your next few commissions and which one is currently active. More detailed versions can show milestone status, estimated turnaround, slots open for booking, or current revision count.
Visually, the overlay sits in a corner of your stream, usually 250 to 400 pixels wide, styled to match the rest of your layout. It updates without you doing anything when the underlying data changes. A client whose piece just moved from "queued" to "in progress" sees the change reflected on the stream the next moment.
The value is split across three audiences. Your viewers see context for what you're working on and a peek at your booking activity. Your active client sees their project highlighted, which makes them feel attended to. Your future clients see a visible queue depth, which is social proof that you're booked, and any open slots, which is a soft conversion prompt.
Nothing about a queue overlay is technically hard. The reason most artists don't have one is that the typical commission stack doesn't surface the data in a form OBS can read. The data exists, it just lives in seven different tools and none of them talk to OBS directly.
Every modern stream overlay, queue or otherwise, works through the same mechanism: an OBS Browser Source.
According to the official OBS documentation, a Browser Source is "quite literally, a web browser that you can add directly to OBS. This allows you to perform all sorts of custom layout, image, video, and even audio tasks. Anything that you can program to run in a normal browser (within reason, of course), can be added directly to OBS."
Under the hood, the Browser Source is powered by Chromium Embedded Framework, the same engine that runs Google Chrome. The obs-browser plugin repository confirms this: "A Browser Source allows the user to integrate web-based overlays into their scenes, with complete access to modern web APIs."
In plain language, a Browser Source is a tiny invisible web page rendered into your OBS scene. If you can put something on a web page (a queue list, a chat widget, a follower counter, a progress bar), you can put it on your stream.
The key properties of a Browser Source, per the official docs:
URL or Local file: where the page lives. URL is for hosted overlays; local file is for self-contained HTML files on your machine.
Width and Height: the viewport the page renders into (defaults: 800 x 600). This is the dimensions of the source inside OBS, not the position on your scene.
Custom CSS: by default OBS injects CSS to make the background transparent, remove body margins, and hide scrollbars. This is why overlays "just work" with transparent backgrounds; OBS is making the page transparent for you.
FPS: refresh rate for the rendered page. Default 30. Most overlays don't need more.
Shutdown source when not visible: unloads the page when hidden, which can save resources but breaks any persistent connections (like a WebSocket pulling live queue data).
Refresh browser source when scene becomes active: reloads the page each time you switch to the scene.
That's all the OBS side of this. There's no special "queue widget" feature; it's the same Browser Source that powers chat widgets, alerts, donation tickers, and everything else.
The URL or local file in the Browser Source has to point to something that displays your queue. There are three broad approaches.
Manual static HTML. You write an HTML file by hand with your current queue listed in it, save it locally, and point the Browser Source at it. The page never changes unless you edit and save the file. This works for "first stream of the day, set it and forget it" if your queue doesn't change during the stream. It does not update live.
Manually maintained third-party page. You use a service like StreamElements or Streamlabs to build a custom widget, and you manually update it through their dashboard between sessions. Closer to live but still manual.
Live data-driven overlay. The page pulls your real queue from your workflow tool (via a public URL or an API key) and updates automatically as the queue changes. This is what most viewers picture when they think of a "queue overlay" and what almost no commission artist actually has, because building the data pipeline is real work.
The first two are achievable in an afternoon. The third is where it gets interesting and is also where the value lives. A queue overlay that requires manual updating is a tool that will silently fall behind reality every time you forget to refresh it. The viewer eventually notices that "in progress" hasn't changed in two streams, and the overlay loses its credibility.
Before you write any code, decide what the overlay actually shows. The temptation is to put everything on screen. Resist it. Stream overlays are read in peripheral vision; if a viewer has to study your overlay, you've lost.
Useful elements, ranked roughly by value:
Current project name (just a handle or first name, never a full real name). Tells viewers who they're watching you work for.
Next 3 to 5 in queue. Bookers want to know if you're booked out.
Status indicator on the current project. Sketch / Lineart / Color / Revision. Subtle, single word, no emoji.
Slot availability. "3 slots open" or "Books closed" is a strong soft-sell. If you take open commissions, this drives bookings.
Active milestone progress bar. Optional. Looks nice but adds visual weight.
Skip or hide:
Full client names, real names, or email handles. Privacy issue and unnecessary.
Dollar amounts. Distasteful on stream and exposes sensitive info.
Long descriptions of each project. Nobody reads them and they eat screen real estate.
Personal notes or to-do items. Belongs in your project tool, not your stream.
A clean queue overlay shows three to five lines of small text, in your stream's existing font, in a corner. It does not need a background panel, a border, or animations. The less it draws attention, the more useful it is.
Sizing inside OBS: 300 pixels wide by 200 to 400 tall is typical, depending on how many lines you show. Position it bottom-left or bottom-right, away from your main canvas if you're drawing on stream. Test it at 1920 x 1080 on whatever monitor a viewer is most likely to use.
Once you have a URL or local HTML file with your queue display, the OBS part is fast:
In OBS, in your scene where you want the overlay, click the + under Sources.
Choose Browser from the list.
Name the source something obvious like "Queue Overlay".
In the properties panel, paste the URL into the URL field, or check Local file and browse to your HTML file.
Set Width and Height to roughly the dimensions you want the source to occupy (e.g. 300 x 400).
Leave Custom CSS at the default; it handles transparency.
Set FPS to 30 unless your overlay has animation that needs higher.
For a queue that updates via long-running connection (WebSocket), leave "Shutdown source when not visible" unchecked. For a queue that polls (refetches periodically), it doesn't matter.
Click OK. The Browser Source appears in your scene. Drag and resize it to position.
Refresh the source (right-click in Sources, choose Refresh) any time you want to force a reload during testing.
That's it on the OBS side. If your overlay is working in a normal browser at the URL you pasted, it will work in OBS.
Before going live with an overlay, run through this checklist on your own setup:
Open the URL in a regular Chrome browser. Does the page render with a transparent background by default? If it has its own opaque background, your overlay will block whatever's behind it in OBS. The page needs to handle transparency itself or rely on OBS's default custom CSS.
Resize the Chrome window to the dimensions you set in OBS (e.g. 300 x 400). Does the overlay still look right at that size, or does text wrap awkwardly? Adjust the page or the source dimensions.
Make a test change to your queue (advance a project, mark a slot taken). Does the overlay update without you touching anything? Time how long it takes; anything under 10 seconds reads as "live" to viewers.
Hide the OBS scene with the overlay, then unhide it. Did the overlay reload correctly? Did it remember its state, or is it showing stale data?
Stream-test it. Open a private test stream on Twitch or YouTube, look at your own broadcast on a phone or second device. Does the overlay render the same way it does in OBS preview? Is the text readable at typical viewer zoom levels?
If any of these fail, the issue is almost always on the page side (HTML, CSS, or data feed), not the OBS side. Browser Source is just rendering whatever the page does.
The technical work above is straightforward. The reason most commission artists don't have a working live overlay isn't because OBS is hard or because they can't follow a guide. It's because the data pipeline doesn't exist in their setup.
If your queue lives in a Trello board, your active project lives in a Discord thread, your client names live in a spreadsheet, and your milestones live in your head, then the overlay has nothing to pull from. To make a live overlay, you would first need to consolidate that data into a single source the overlay can read from, and then build the page that reads from it and renders nicely on stream. That's a software project, not a streaming tweak.
The artists who have working overlays generally fall into two groups. Either they're technical enough to have built their own backend (a small percentage), or they use a workflow tool that exposes the queue data in a stream-readable format out of the box.
This is the gap StudioQueues was built to close. The queue, the milestones, and the active project state all live in one workflow, and there's a queue overlay endpoint you point your OBS Browser Source at. The overlay reads live from the same data that runs your business, so what your client sees in their account and what your viewers see on stream are always in sync. The audience-facing layer pulls from the same place as everything else; no parallel manual updates, no stale data, no separate spreadsheet to keep in sync.
StudioQueues is built around this stream-native integration. The OBS overlay, chat command integration for viewer status checks, go-live alerts for clients when their commission is the active project, and audience-facing queue visibility are part of the product, not a sidecar tool. Founding artist spots include 0% platform fees for life, and there are only 500 of them.
Once a queue overlay is running, the change in your stream is subtle but real. The chat stops asking "whose are you working on?" every fifteen minutes because they can see it. Returning viewers can tell that the queue moved since last stream, which makes the work feel like ongoing progress instead of a single endless stream. New viewers landing on your stream get instant context for what they're watching, which improves your retention numbers because they don't bounce as fast.
For your clients, the effect is bigger. A client whose piece just became active gets a small, public moment of being-the-active-project. They tend to tune in to streams when their piece is up, which is good for your stream metrics and good for them. Clients waiting in queue can check the overlay on their own time and don't have to message you for status updates, which means fewer interruptions for you.
For your business, the overlay is quiet marketing. A visible queue with slots showing as taken is the kind of social proof that drives bookings. A visible "1 slot open" is a direct conversion prompt that you didn't have to write.
A commission queue overlay is one of the highest-leverage additions to a commission-focused stream. It improves viewer experience, client experience, and conversion all at once, with no recurring effort once it's set up. The technical mechanism is simple: an OBS Browser Source pointing at a page that shows your queue.
The hard part is the page. Building it from a fragmented tool stack is a software project most working artists don't have time for. Building it from a workflow tool that exposes the data natively is fifteen minutes of OBS configuration and you're done.
The artists who run the calmest, most professional commission streams are not the ones with the fanciest overlays. They're the ones whose overlays are tied directly to the same workflow that runs everything else, so the stream and the business stay in sync without anyone having to keep them that way.
