Dev.to WebDev πŸ›  Dev πŸ‘ 0 πŸ“– 4 min read

What Goes Over the Network When You Use the Browser Studios: A Seven-Studio Audit

I work on OnePassApps, so this is a measurement of our own product rather than a review of somebody else's. Every Studio post on this site says the file stays in the tab. I wanted to check that claim the way a sceptical

I work on OnePassApps, so this is a measurement of our own product rather than a review of somebody else's.

Every Studio post on this site says the file stays in the tab. I wanted to check that claim the way a sceptical reader would: open the app, watch the network, and see exactly what crosses the wire. So I opened all seven Studios, clicked through every tool tab in each one, and logged every request the browser made.

What I measured

One Chrome session, signed out, on 3 November 2026. For each Studio route I turned the network log on before the page was even requested, so page load was included, then clicked every tab on that page in turn. In one route I also dropped a real file onto the stage and ran the tool for real.

The result comes down to one line: 968 requests, and not one of them carried a body.

The totals

Studio Requests GET OPTIONS Requests with a body
Image 140 140 0 0
Audio 140 140 0 0
Text 137 137 0 0
Data 138 138 0 0
Icons 139 139 0 0
Files 135 135 0 0
Colour 139 136 3 0

That is 965 GET and 3 OPTIONS across the session. The three OPTIONS are CORS preflights for the API calls below. No POST, PUT, PATCH or DELETE at any point, and no request of any kind carried a request body - which is the shape you would expect if no file data is being sent anywhere, because a file upload has to go somewhere in a body.

The only three API paths that were ever called

  • https://api.onepassapps.com/api/auth/config
  • https://api.onepassapps.com/api/config/feature-flags
  • https://api.onepassapps.com/api/runtime

All GET. All with empty bodies. These are app-shell calls - sign-in configuration, which features are switched on, and runtime configuration. They happen on page load, before any file has been selected, and they carry nothing out of the tab.

The third party, stated plainly

Cloudflare's analytics beacon is the one request that goes to a host that is not ours: static.cloudflareinsights.com, one script load per Studio page, seven across the session. It is a request, it does happen, and it belongs in an audit like this one. It carried no file data - nothing in the whole session carried a body - but I would rather name it than let "nothing leaves the tab" quietly hide it.

Sign-in runs through Clerk on clerk.onepassapps.com, which is our own domain but a separate auth service: also GET, also empty, ten requests per Studio page for the sign-in UI itself.

A real file, a real run, three requests

This is the part that matters. On the Image Studio Compress tab I dropped a real 64 x 64 PNG of 209 bytes onto the stage and clicked "Compress image". During that operation exactly three requests happened:

GET  https://app.onepassapps.com/assets/image-worker-DtFXhbzj.js   body 0 bytes
GET  blob:https://app.onepassapps.com/e05e447e-f74d-401b-b304-3fd77f9bd6a7   body 0 bytes
GET  https://api.onepassapps.com/api/config/feature-flags             body 0 bytes

The first is the worker script the compressor runs in. The second is that same worker, instantiated as a blob inside the tab. The third is the feature-flags call the page makes periodically. The PNG went into the worker and the result came back out of it; the bytes of that file appeared in none of the three requests, because none of the three requests had a body at all.

The tool was honest about its own output, too. The panel read "Original: 209 B Β· Re-encoded: 785 B" and "Compressed in 0.1 s", and the result line said 276% larger with the heading reading "Larger" instead of "Smaller" - because re-encoding a 209-byte PNG as JPEG genuinely does make it bigger. The file never left, and the tool did not pretend the file got smaller.

What this does not prove

A network log can only show what happened inside it, so here are the limits:

  • One browser, one signed-out session, one build, one day. A different build or a signed-in session can behave differently.
  • I clicked every tool tab in every Studio, but I ran one file operation end to end - the image compression above. In the same session a 22-byte CSV was attached in the Data Studio and its Format JSON button clicked, and that click produced no request either. I did not complete a run in the File Studio's hash tool, so this post makes no claim about what that one does on the wire.
  • No request body is strong evidence, not proof. It shows the file was not sent as a payload. I checked the URLs too: every one I recorded is an asset path, one of the three API paths, a Clerk endpoint or the Cloudflare beacon, and no URL carried file content.
  • I did not exercise anything that spends credits, so the credits API path was not observed in this audit.
  • The app shell does call our API, and Cloudflare does get a request. "Nothing leaves this tab" is a claim about your file, not a claim that the browser is offline.

If you want to repeat the check on any browser tool, the DevTools Network panel with "Preserve log" ticked is the whole method: load the page, run the tool, and read the Method column. A tool that uploads files cannot hide them there.

Standard is currently free during a promotional period: $0 per month, 100,000 credits every 30 days, no card required, and no automatic paid subscription. Existing paid subscriptions keep their terms.

Open the Studios and watch the network yourself and the app guides explain what each tool does.

OnePassApps Team

πŸ“° Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.