OBS 33 Beta Checklist: New Browser Source Engine, Plugin Folders, and Safe Mode WebSocket

What is actually in the OBS 33 beta

As of today (October 8, 2026), OBS Studio 33.0.0 is still a prerelease. The GitHub releases page shows Beta 4 on September 25, Beta 5 on October 1, and Beta 6 on October 2, and the latest stable build is still 32.2.2 from August 14. I did not find a stable 33 release or a release candidate, and I did not find an announced release date. If you are searching for the OBS 33 release date, nobody outside the OBS team can give you one yet, and this page will not guess.

Three things in the notes matter more to an overlay builder or a producer with remote tools than the rest of the changelog. First, the browser engine (CEF) jumped from 127 to 150. Second, third-party plugins get a new install location and folder structure. Third, Beta 6 changed Safe Mode so it does not start the WebSocket server. Everything else in the notes is smaller.

Betas 2 to 4 were CI, packaging, and versioning fixes with no application changes since Beta 1. Beta 6 is the one to install, since it also fixes a group crash, macOS scripting, and game capture hook updates that were broken in Betas 1 to 5.

Why a browser engine jump is not invisible to you

The release notes call the CEF update a massive backend change that should be invisible, and ask people to report any new weirdness with browser sources. They also say it spans the July 2024 release to September 2026. That is a lot of Chromium under your alerts, chat boxes, and dashboards.

Most overlays will probably look the same. The ones to worry about are the old ones: a chat box someone coded in 2022, an alert page that relies on a quirk, a CSS trick that was only ever tested against whatever Chromium OBS happened to ship. I am not claiming any specific overlay will break. I am saying you cannot know until you load your own pages in the new build.

The staging plan: separate machine, copied data, one variable at a time

Do not install a beta over your working OBS. Use a different computer, or at minimum a portable install in its own folder, so the beta cannot touch the install you stream from. The plugin KB notes that Windows portable mode has its own plugin location, which keeps the test self-contained.

Copy your profile and scene collection into the test install and rename them with the version and date. I would also work from copies because a newer build may write scene collection data that an older build handles differently. I have not verified that for 33, so treat it as a reason for caution, not a known fact.

Change one thing at a time. First load the scene collection with zero third-party plugins and check browser sources. Then add plugins back in groups. Then enable WebSocket and test your tools. If you do everything at once and something fails, you will not know whether the engine, a plugin, or a setting did it.

• Test machine only. Never the computer you stream from.
• Copy profile and scene collection, then rename the copies.
• Decide in advance what counts as a fail, so you are not negotiating with yourself mid-test.

Browser source pass/fail checklist

Run each of these in the test build with your real URLs, not a demo page. A pass means it matches the stable build on the same scene. A fail is anything a viewer would notice.

Custom overlays (your own HTML, CSS, JS): the page loads at its set width and height, transparency still works with the default custom CSS, and local files still load from the same path. Fail on a solid background where it used to be transparent, clipped elements, or fallback fonts.

Alert pages: fire a test alert from the alert provider and watch the full cycle. Sound plays once, the animation finishes, and the next queued alert follows. Fail if audio is missing or doubled, an alert freezes mid-animation, or the page stops responding after the third or fourth test.

Chat boxes: leave a busy chat running for 20 minutes. Messages should scroll, emotes should render, and nothing should stall. Fail if it stops updating, emotes go blank, or CPU climbs while the page sits idle.

Scene change behavior: if you use Shutdown source when not visible or Refresh browser source when scene becomes active (both default to off), switch away and back a few times. Pass means the page comes back in a sane state. Fail means it reloads into a blank, stale, or duplicated state.

• Open the same URL in a normal browser as a control. If it is also broken there, the problem is the page, not OBS.
• Compare CPU and GPU use against stable on the same scene. A big jump is a finding even if everything looks fine.
• Check any custom browser docks, not only sources.
• Log each page as pass, fail, or odd, with the build number. Odd gets retested on the next beta.

Plugin inventory and location audit

The notes say first-party plugins move to a new folder named core, third-party plugins get an updated install location and folder structure, and existing third-party plugins keep loading from legacy locations until OBS Studio 34.0.

So for 33, the legacy setup should still work. The knowledge base page says OBS tries the new location first, and if that works it skips the legacy copy of the same plugin. On Windows, the new layout puts the module straight in its plugin folder under ProgramData, for example a plugin folder with the dll next to its data folder, instead of nesting it under bin and 64bit. As I read the page, plugins that were incorrectly installed under Program Files are flagged and will not load in 34.0 and later. The page said macOS locations are not changing and that Linux details were still to come, so check it again before you rely on that.

Do the audit before you install the beta. List every third-party plugin on your production machine, note where each one lives on disk, and note whether it came from an installer or a manual copy.

Then check each one against its own project page, because the plugin author decides when to ship an update to the new layout. A plugin that loads fine in 33 through the legacy path can still be a problem for 34.

• Make a table: plugin name, version, install path, installer or manual, author page checked.
• Move anything installed under Program Files to wherever its author now says it should go, in the test install first.
• Check the OBS log after launch for each plugin you expect to see.

Safe Mode and WebSocket: what changed and how to test it

Beta 6 changed Safe Mode so it does not start the WebSocket server. The reasoning in the obs-websocket pull request is that with the plugin manager changes, obs-websocket now loads as a core module even in Safe Mode, and Safe Mode is supposed to mean no third-party code runs while you hunt for the cause of a problem. The release notes add that third-party plugins are not loaded in Safe Mode.

The same pull request says the server's enabled setting is not changed unless you open the WebSocket server settings and click OK or Apply, and that you can still switch the server on from that dialog while in Safe Mode. That detail matters for anyone who recovers from a crash by launching Safe Mode and expects their control panel to reconnect on its own.

If your tools use OBS WebSocket (stream decks, scene buttons, bots, producer panels), the failure to prepare for is simple: OBS comes up in Safe Mode after a crash, the tool shows disconnected, and someone assumes the network is broken.

• Launch the test build normally and confirm every tool connects with your usual host, port, and password.
• Launch it in Safe Mode and confirm the tools cannot connect. If they can, that is worth noting, since it is not what Beta 6 describes.
• In Safe Mode, enable the server from the settings dialog, reconnect a tool, and check that it works. Then restart normally and see what state the setting is in.
• Run your core actions after connecting: read the current scene, switch a scene, toggle a source, mute and unmute a mic. Check the result on screen, not only in the tool.

Rollback plan

Write the rollback before you need it. Keep the installer for your current stable build (32.2.2 at the moment) somewhere you can reach it without an internet connection. Keep your working profile and scene collection in a folder with a date on it.

If the beta is a separate install or a portable copy, rollback is closing it. If you did install it over your normal OBS despite the advice above, uninstall, reinstall the stable build, and restore the copied profile and scene collection, then open it once on a quiet day to confirm.

What to do on show day

Do not run a beta on the live machine. Show day is for the setup you have already trusted. A problem found the afternoon of a stream is information for next week.

What you can do on show day is small and useful. Confirm your WebSocket tools connect. Open every browser-source scene once and look at it. Keep your normal fallback scene and BRB scene ready and test that the producer can reach them.

What we do not know until stable ships

Several things are open. The release date is unannounced. The contents could still change before stable. I have not run this beta, so I cannot tell you how your overlays behave, and this guide does not report test results.

We also do not know how third-party overlay and alert providers will respond. Plugin authors will update on their own schedules, and the Linux plugin location details were still marked as coming.

The release notes say existing third-party plugins load from legacy locations until 34.0, and the knowledge base article confirms the Program Files layout stops loading then. It is vaguer about the other legacy layouts, saying only that they will not load in the future. 34.0 has no date. Treat that as a reason to tidy plugin folders on your own timeline, not an emergency.

Where StreamableRun fits

StreamableRun runs OBS in the cloud for IRL streamers, and in that kind of setup the program output does not depend on the computer in your room. I do not know which OBS version any particular cloud production runs, and this guide does not claim anything about it. Changes in a hosted setup arrive on the provider's schedule, not yours.

What you can do on your side is cheap. Test your overlays and WebSocket tools against a local OBS beta first, so you know what needs fixing before any change reaches a show you care about. StreamableRun uses OBS WebSocket on the server side for things like the clips player, moderator controls, and managed overlays, with moderator roles such as Admin Moderator, Scene Switcher, and Tools Moderator. An Ingest Offline fallback scene exists for when the feed drops. Whatever your setup, rehearse that fallback regularly so a browser source problem does not take the whole show with it.

Decision list

Pick the lines that match you.

• Lots of custom or old browser overlays, or docks? Test Beta 6 on a spare machine soon, browser checklist first.
• Depend on third-party plugins? Do the inventory now, and test the plugin location behavior in a separate install.
• Use WebSocket tools during shows? Test Safe Mode behavior and reconnect handling before stable.
• Run a simple setup with few plugins and no custom overlays? Staying on 32.2.2 until stable and its first patch is reasonable.
• Streaming this weekend? Leave production alone.

Other resources

Check these primary pages again right before you test, since beta notes and the knowledge base can change.