OBS 33: a "Local file" browser source can't reach localhost or your local network

What breaks

We ran OBS 32.1.2 and 33.0.0 side by side on 24 October 2026, using test overlay pages and test services at simulated addresses (see How we tested). Each page asked each service for data in five ways: fetch, XMLHttpRequest, EventSource (server-sent events), an <img> tag and a WebSocket.

So an overlay that talks to its tool over a WebSocket keeps working on 33. An overlay that polls the tool over HTTP, listens for server-sent events, or loads images from it stops getting anything if it is loaded as "Local file".

How to tell if this is your problem

OBS writes browser-source errors to its log (Help → Log Files → View Current Log). On OBS 33.0.0, each blocked request from a "Local file" overlay logged a line like this in our test:

[obs-browser: 'Overlay'] Error: Access to fetch at 'http://127.0.0.1:9000/ping' from origin 'http://absolute' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `loopback`.

Overlay is your source's name. For a device on your network the line ends in address space `local` instead. from origin 'http://absolute' means the overlay was loaded with "Local file". The https-to-network hang in the next section but one logged nothing at all.

The fix: serve the overlay from 127.0.0.1

1. Open a terminal in the folder that holds the overlay's HTML file and start a small web server. With Python 3 installed:

   python3 -m http.server 8080 --bind 127.0.0.1

   That is the command we ran. On Windows the Python launcher is usually py instead of python3; we did not test Windows.

2. In the browser source's properties, untick "Local file" and enter the URL http://127.0.0.1:8080/overlay.html, with your file's name in place of overlay.html.

3. Leave the terminal open while you stream. The overlay loads only while the server runs.

We ran exactly that command in the test overlay's folder, with no other server settings, and loaded the overlay at http://127.0.0.1:8080/ on OBS 32.1.2 and 33.0.0. Every request worked on both versions, 25 of 25: to this computer, to private network addresses over http and https, and to public addresses, with every request kind. In the same run, the same page loaded as "Local file" failed 12 of 25 on 33.0.0. Chromium counts a page on 127.0.0.1 as a secure page, and our test page reported itself as one on both versions.

Two things to check after the move. Keep everything the overlay loads inside the folder you serve. And if your tool only accepts requests from certain pages (its CORS settings), it now has to accept http://127.0.0.1:8080; our test services accepted every page.

The obs-browser developers already call the http://absolute/ handler "legacy functionality dating back to the original OBS Classic" and wrote that they "should consider removing" it in a future update (pull request 551). Moving an overlay off "Local file" now also avoids that change later.

An https overlay that calls another device over https hangs

This one affects overlays hosted on a website, not local files. If the page calls a device on your local network over https, such as a second computer that serves an https API, the request on OBS 33.0.0 neither succeeds nor fails. (In our test, both the page and the "device" were simulated addresses on one machine.) Nothing came back within 6 seconds, the limit our test page waited, and no error appeared in the log. An overlay that waits for that reply will simply stop updating. The same calls worked on 32.1.2.

What still worked from the same page: a WebSocket (wss://) connection to the same device, and calls to this computer (http://127.0.0.1). If the device offers a WebSocket, use that. Calls over plain http from an https page to a device on your network were already blocked on 32.1.2 as mixed content, so they are not new in 33.

The launch flag, and what it costs

On Linux we also started OBS 33.0.0 with this command-line switch:

obs --disable-features=LocalNetworkAccessChecks

It fixed every failing request in the table above. It also broke 4 requests that 33.0.0 had newly allowed: an overlay served over https from an address on your network that calls a plain-http service at another address on your network. 32.1.2 blocked those as mixed content, 33.0.0 let them through, and with the switch they were blocked again. The switch turns off a browser security check for every browser source and dock, and the obs-browser developers decided against it in pull request 547 because it "has a wider scope of side effects" than they were comfortable with. We list it because we measured it, not as a recommendation. We did not test the switch on Windows or macOS.

How we tested

We installed the official Ubuntu packages of OBS Studio 32.1.2 and 33.0.0 from the project's GitHub releases, checked each file against the SHA-256 digest published with the release, and ran each one in a disposable Linux container with no network connection and no GPU (software rendering under Xvfb). Each version ran on the Ubuntu release its package was built for: 32.1.2 on Ubuntu 24.04, 33.0.0 on Ubuntu 26.04. So the two runs differ in more than OBS. The launch-flag run is the check on that: the same 33.0.0 on the same Ubuntu 26.04, with only Chromium's Local Network Access checks turned off, made all the failing requests work. Every address was simulated inside that one container. We added the private (192.168.x.x) and public addresses (from the range reserved for documentation) to the container's own network interface. No second computer, physical network or internet server was involved. Chromium decides what is local, private or public from the IP address, so we expect a real device or server at such an address to be treated the same way, but we did not test one. Six browser sources loaded the same test page from six places: a "Local file", http://127.0.0.1, a private address over http and over https, and a public address over http and over https. The test services ran on 127.0.0.1, on a private address over http and https, and on a public address as a control. Every service answered with permissive CORS headers. The page served from 127.0.0.1 for the six-source runs came from a small Python server built on http.server; the fix command was then run as printed, in a separate run of each stable version. The page wrote each result to the OBS log; that log is what we counted. A request that had not finished after 6 seconds was recorded as a hang.

Each version ran once on 24 October 2026, and 33.0.0 ran a second time on its saved profile: the two 33.0.0 runs agreed on every result. As a check that the test really exercised the new rules, the 33.0.0-beta6 release, which came before the localhost permission was added, failed an https page's calls to localhost (they hung), the problem reported in issue 545. The calls to the simulated public control services worked on every version, except the ones that mixed-content rules block on every version (an https page calling a plain-http service).

Not tested: Windows and macOS, where most streamers run OBS. Our beta6 run already behaved differently from that Windows report: requests hung on Linux, where the report shows "Permission was denied". Also not tested: any named overlay, widget or tool, only our test pages; graphics (WebGL), because our containers had no GPU; and how many overlays combine "Local file" with calls to a local tool, which we did not measure. The 6-second limit is our test's, not a Chromium timeout.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something on this page is wrong or has changed, email hello@cybernative.ai. We correct the page and list each correction here with its date.