I work on OnePassApps, so this is our own product, and everything below is a measurement of the live site at app.onepassapps.com taken on 4 November 2026 - signed out, in one browser, on one build.
The question this answers is a small one that every browser tool eventually gets asked: if I paste my data into this page, where does it actually go, and can a link bring me back to where I was? On OnePassApps the answers turned out to be unusually clean in one direction and surprisingly empty in the other.
Everything here was measured two ways: plain HTTPS GETs from outside the browser (status codes, redirect targets, canonical, robots, byte sizes), and the live app in the visible Chrome on display :1 (what the browser actually lands on, and what is sitting in browser storage afterwards).
The route map: what answers, what redirects, what 404s
The site's sitemap.xml lists 16 public URLs. The server answers more than that, and the answers are not all the same kind of answer.
| Request | Answer | Where it lands |
|---|---|---|
/ |
200 | home page |
/pricing |
301 | /plans |
/studios |
301 | /studios/image |
/privacy |
301 | /terms#privacy |
/guides/ |
308 | /guides |
/studios/data/ |
308 | /studios/data |
/plans/ |
308 | /plans |
/studio/data (singular) |
404 | "Page not found — OnePassApps" |
/studios/DATA (wrong case) |
404 | "Page not found — OnePassApps" |
/nonexistent-xyz |
404 | "Page not found — OnePassApps" |
/account |
200 | then the client sends a signed-out visitor to the home page |
/sign-in?return_to=%2Fsupport |
200 | "Sign in — OnePassApps" |
Three details worth pulling out.
Redirects come in two flavours. /pricing is a permanent 301 to /plans - an old name for a page that still exists. A trailing slash is a 308, which is the "permanent, but the method and body are preserved" code. The 301s are editorial decisions about a page that moved; the 308s are a normalisation rule about how the path is spelled.
The 404 is a real page, and it is the same size every time. Every unknown path returned a body of exactly 13,953 bytes with the title "Page not found — OnePassApps", robots set to noindex, nofollow, and no canonical tag. The byte count is identical but the SHA-256 differs for each path, which means the path itself is echoed into the response rather than the server sending one cached blob.
Case matters. /studios/DATA is a 404, and /studio/data - the singular - is a 404. The URL space is exactly the 16 lowercase paths in the sitemap plus the handful of redirects above. There is no silent aliasing of a typo onto the page you meant.
The 404 page is not a dead end
Rendered in the browser, the 404 page is one of the more useful pages on the site. Its heading reads "That page doesn’t exist", the line under it says "Nothing is published at this address. Pick an app below, or search every app.", and it offers a Browse all apps control and a Go to Home control. Below that it lists the full roster with working links: MovieMatcherAI (LIVE APP · FILMS), NewsFlow (LIVE APP · NEWS), and the seven studios. It also carries the pricing band - "FREE PROMOTIONAL PERIOD", "Standard is free right now", "$0 / month", "100,000 credits every 30 days", "No end date set", "No card required".
So a broken link into the site does not strand a visitor: it lands on a page that shows every app that does exist, and it says what is free.
The URL is not the state
Here is the part that surprised me, and it is the opposite of the usual "shareable state" pattern.
Loading https://app.onepassapps.com/studios/data shows the Viewer tab selected, with eleven tabs available: Viewer, Sort / filter, Columns, Duplicates, Merge, Split, To JSON, Formatter, Validator, To CSV, YAML.
-
https://app.onepassapps.com/studios/data?tab=columns- still Viewer. -
https://app.onepassapps.com/studios/data#columns- still Viewer. -
https://app.onepassapps.com/studios/data?tab=To%20JSON- still Viewer.
The query string and the hash are both ignored by the tab strip, and clicking Sort / filter does not push anything into the address bar either - the URL stays https://app.onepassapps.com/studios/data. Reload the page and you are back on Viewer: the tab you were on is not restored.
The contrast with the other apps is the interesting part. MovieMatcherAI does put its view in the URL - loading /apps/movie-tracker ends up at /apps/movie-tracker?view=browse&discover=new-releases in the browser, so its state is linkable. That rewrite happens in the client, not on the server: a plain GET of the bare path answers 200 with no redirect header and a canonical of https://app.onepassapps.com/apps/movie-tracker. The Studios are the opposite: their state is in memory only, and a bookmark points at the studio, not at the tab.
For an in-memory studio tool that is a defensible design - there is no artefact in the URL to go stale, and nothing about your file can leak into a shared link. But it does mean one practical rule: if you want to come back to a specific tool, download the result, do not bookmark the tab.
What actually lands in browser storage
After visiting the home page, /support, /voting, /plans, /apps/newsflow, /apps/movie-tracker and /studios/data in a signed-out session, this is the complete inventory.
localStorage, four keys on every page:
-
__clerk_environment- the Clerk sign-in configuration blob. -
onepass:recent-apps- the ids of recently opened apps, e.g.["studio:data","studio:colour","studio:icons","studio:files","studio:image","studio:text","studio:audio","product:signaldesk"]. This is what feeds the Recent strip in the site header. -
toolpass-theme-preset- the theme choice,"graphite"on this browser. -
toolpass-store- app state:favouriteProductIds,recentProductIds,selectedProductSlug, and a dismissed-prompt flag.
sessionStorage:
-
toolpass.feature-subject.v1- one hash, on every page. -
signaldesk.public-inbox.reviewed-feeds.v4- only on NewsFlow and MovieMatcherAI.
Cookies: two, __client_uat and __client_uat_CLGjHovd, both 0, which is what a signed-out Clerk session looks like. No analytics identifier, no advertising identifier, no cross-site id of any kind.
Your data is not in any of it. I pasted a two-row CSV into the Data Studio source box with a marker string in both cells (zeppelin-marker-9931), clicked Parse CSV, and got "Loaded 2 rows and 2 columns" and "2 rows · 2 columns · no parsing issues" in the result panel. Then I dumped every byte of localStorage and sessionStorage: the marker string appears in neither. The parsed rows live in the page's memory and are gone on reload.
That is the same claim the studios make in their own words - "Nothing leaves this tab" - and this is how it holds up: not as a promise about a network tab, but as an absence in the browser's own storage.
The honest limits
- Signed out, one browser, one build, one day (4 November 2026). I did not sign in, so what a signed-in account stores is not covered here, and the Clerk environment blob is listed by key name only, not read in full.
- Status codes and redirect targets are what this network's edge returned. A different point of presence could answer differently for the 404 and the 308s.
- I did not inspect the contents of IndexedDB beyond confirming the API is available, and I did not look at Cache Storage.
- The storage inventory was taken from the visible Chrome profile on display
:1; another browser would carry its own set of keys for its own reasons. - No phone or tablet was tested, so nothing here is a claim about mobile behaviour.
Why it is worth checking yourself
Most "it runs in your browser" claims are marketing until you look. Three checks take two minutes and settle it for a site you have never used: open DevTools and look at what the Network tab sends (or does not), dump localStorage after pasting something recognisable into the tool, and try a link with a query string to see whether it lands where you expect.
For OnePassApps the answers are: the network carries the app shell and your API calls but no file bytes, the browser storage holds four configuration keys and no user data, and a Studio link takes you to the studio rather than to the tab you were using.
If you want to see it yourself, open the Data Studio - the one every measurement above was taken in - or read the app guides first.
Top comments (0)