If a note app runs in a browser tab, what you type goes somewhere. When that somewhere is not a server, the answer is still not a folder you can open in a file manager; it is an area the browser sets aside for that site, called an origin, and although it sits on your own disk the rules belong to the browser rather than to you. The quota varies by device. Under certain conditions the browser empties the whole thing without telling you.
Three stores doing three jobs
What a web app can write to is not one pool.
localStorage is the oldest and the narrowest: a 10 MiB ceiling shared with sessionStorage, and because it is synchronous, writing anything large holds the interface still while it works. Small things go there. A theme choice, the last open tab, a preference.
IndexedDB is the layer that does the real work. It has records, indexes and queries, so notes, tasks, tags and the search index all live there.
The Origin Private File System is the third and newest. It behaves like files and can be written in chunks, which is why large attachments such as PDFs and images land in that layer without being loaded into memory whole. All three eat from the same quota. So moving attachments to a different surface to save room is not a thing.
The disk sets the quota, not you
There is no fixed megabyte figure, because the quota is calculated as a percentage of the device’s disk and every browser picks its own percentage. In Chrome and Chromium-based browsers the per-origin ceiling is roughly sixty per cent of the disk. Firefox gives the smaller of ten per cent or 10 GiB in the default mode, rising to fifty per cent in persistent mode. Safari sits near sixty per cent in the browser app; inside an in-app web view it is about fifteen.
What that means in practice: the same workspace fits comfortably on a 512 GB laptop and can press against the ceiling on a 64 GB tablet. navigator.storage.estimate() reports the real number on that device. The number it reports is an estimate.
Deletion arrives through two doors
The first is storage pressure: when the device runs low, the browser starts with the least recently used origin and works backwards, and the deletion is never partial, because a half-emptied database produces worse outcomes than an inconsistent app. When an origin is cleared, everything goes. IndexedDB, OPFS and localStorage together.
The second is specific to Safari and comes up far more often. With cross-site tracking prevention on, storage written by JavaScript is deleted if the origin sees no interaction across seven days of browser use; interaction here means a click or a tap, so leaving the tab open in the background does not reset that counter.
The full rules and the differences between browsers are set out in MDN, “Storage quotas and eviction criteria”.
What persist() buys
navigator.storage.persist() asks for permission to mark the origin persistent, and if that is granted the data only goes when the user clears it from browser settings, with storage pressure no longer touching it. The browser decides. Firefox asks; Chrome looks at your interaction history and decides silently; Safari decides silently too.
So what you hold is a request, not a guarantee. The only way to learn the answer is to read the value the call returns.
What knowing this changes
The web version of Context runs on exactly this ground, and because sync ships switched off, on day one your entire workspace lives here. Even with a persistence request granted, you are leaning on a promise made by a third party.
That is why exporting stops being a line on a feature list and turns into a habit. Export to Markdown, put the file on another disk, close the loop. Five minutes. You never have to track when a seven-day rule is about to fire.