Offline by Design: Why the OnePassApps Studios Still Work With the Network Cut

I work on OnePassApps, so this is our own product and everything below is a measurement of our own build, taken in the live tab on 4 November 2026.

There is a claim that runs through all seven of our browser studios: the file never leaves the tab. That claim is easy to make and easy to fake. The stronger question is what happens when the network is gone entirely. If the tool only works because a server is answering, then the file stays local but the tool is not really local.

So I cut the network and tried to use the thing.

How this was measured

• Chrome on display :1, driven over the DevTools protocol, with Network.emulateNetworkConditions set to offline: true, downloadThroughput: 0 and uploadThroughput: 0. navigator.onLine then reads false, which is the browser's own signal, not mine.
• The Text Studio at /studios/text, opened fresh, then driven with real key events and real clicks.
• No server-side logging was consulted, no account was created, and nothing on the site was changed.

The first surprise: there is no service worker

This is the part I did not expect. A progressive web app normally installs a service worker - a script the browser keeps and runs offline, with its own cache of assets. Ours does not.

In the live tab, with the page open:

await navigator.serviceWorker.getRegistrations()  // []
await caches.keys()                              // []
navigator.serviceWorker.controller                // null

Zero registrations, an empty Cache Storage bucket, and no controller. The same reading after an offline reload: still zero, still empty, still no controller.

On the server side, the usual service-worker filenames are simply not there:

Path	Status
/sw.js	404
/service-worker.js	404
/sw	404
/worker.js	404
/offline.html	404

Every one of those 404s returns the same 14,320-byte HTML page as the rest of the site's not-found responses. There is no worker script behind any of them.

What does exist is the manifest, at /site.webmanifest - HTTP 200, Content-Type: application/manifest+json, 876 bytes. That file is what makes the site installable on a phone. It is not a cache, and on its own it does nothing for offline use.

So where does the page come from when the network is cut?

From the browser's own HTTP cache. This is the ordinary cache your browser keeps for ordinary web assets - not Cache Storage, which is the service worker's private bucket.

With the network still down, I reloaded /studios/text and read the resource timing entries the browser recorded for that reload:

• 139 resource entries in total.
• 137 of them came back with transferSize: 0 and deliveryType: "cache" - not one byte crossed the network.
• The 139 entries together transferred 895 bytes in total.
• The assets were the normal hashed bundles, for example /assets/index-CKM47TUG.js, /assets/app-shell-shared-D9IUHDyB.js and /assets/react-vendor-Cj1_A1WE.js on the day I measured.

The shell came back complete. The page title was still Text Studio — OnePassApps. All eight tool tabs were there - Clean, Case, Duplicate lines, Sort lines, Find & replace, Diff, Markdown, Base64. The input counter still read 19 / 2,000,000. The plan block still read Standard is free right now, $0 / month, 100,000 credits every 30 days, No end date set, No card required, No automatic paid subscription. Existing paid subscriptions keep their terms.

Two of the five requests the reload tried to make failed, and the rest came from cache. The failures did not break the page.

The tool itself still ran

This is the part that matters. A cached page that cannot do anything is a screenshot, not an offline app.

With navigator.onLine reading false, I typed into the Case tab's input and ran a conversion:

1. Typed hello offline world into the input field. The counter moved to 19 / 2,000,000.
2. Chose the UPPERCASE style.
3. Pressed Convert case.

The result panel came back with:

• Ready
• Converted in 0.2 s
• Converted text 19 characters · 1 line
• Use as input, Download .txt, Copy, Convert again
• Text transformed locally.

And the output field really held the converted text: HELLO OFFLINE WORLD. That is the whole file, byte for byte, transformed on the machine in front of me with no network at all.

The site also told me what it thought was happening, in its own words, in a banner at the top of the page:

You're offline. Tools on this device keep working; live apps refresh when you're back.

What this means, and what it does not mean

What it means. Our studios are not thin clients waiting on a server. The work happens on your device, so it keeps happening when the server is unreachable. That is the difference between "we do not upload your file" and "you can use this on a train".

What it does not mean. Three honest limits:

• A first visit needs the network. The offline reload worked because the shell was already in your browser's HTTP cache. A visitor arriving with an empty cache and no network gets nothing - there is no service worker to answer for us. The offline experience starts at your second visit, not your first.
• Cache rules still apply. The cache that served the page is the browser's normal HTTP cache, subject to the browser's normal eviction rules. If it is cleared or evicted, the next offline load has nothing to draw on.
• The hosted apps are a different question. The banner says live apps refresh when you are back. I tested the Text Studio only, so I am not going to tell you what MovieMatcherAI or NewsFlow do on a dead network - I have not measured it.

Why publish this at all

Because "your file never leaves the tab" is a promise anyone can print on a page, and the only way to tell a promise from a feature is to break the network and watch. This one held up. It held up in the browser's own cache, with no service worker, no special offline mode and no server in the loop.

If you want to see it yourself, the Text Studio is the one I measured - the Case tab is the fastest to try. The app guides cover what each tool does. And if you have a question I have not answered, the vote board is where to put it.