How Browser Storage and IndexedDB Keep Local Work Available—Until You Clear It

When a browser tool restores your PDF project after an accidental refresh, the moment can feel like magic—or like cloud sync. Usually it is neither. The application wrote its state into IndexedDB, a database that lives inside your browser profile on the device in front of you. No upload happened, no account was consulted, and nothing left the machine.

That design is excellent for privacy and speed, and it draws a boundary worth understanding: whatever the browser’s local site data can be erased by, your local workspace shares the same fate. This article explains what that storage is good at, where it lives, exactly how people lose it, and the routine that keeps local-first tools safe to rely on.

What IndexedDB actually is

Browsers give every web application several places to keep data. The oldest and simplest is a small cookie-style key-value store suitable for a few kilobytes of text. IndexedDB is the serious sibling: a real database engine, built into the browser, designed for structured records, indexes over those records, and larger binary values—the raw bytes of a document among them.

Three properties shape daily experience with it:

• Origin-scoped. Data written by crate.anirone.com is visible only to that origin. No other website can read, list, or even confirm its existence.
• Local. Records sit in your browser profile on your disk. Nothing replicates to another device unless the application itself exports a file you carry over.
• Durable but not sacred. It survives restarts, updates, and reboots—yet remains subject to private-browsing rules and the cleanup actions described below.

An editor such as PDF Stage can use this to remember page order, annotations, themes, and imported file data between visits. A diary tool such as Secret Vault keeps the active workspace there while you write. The pattern is the same: the browser becomes the working memory.

What autosave genuinely covers

Situation	What local autosave does
You refresh the page	Restores the working project
You close a tab by mistake	Reopens the workspace later
The laptop battery dies mid-session	Recovers the last saved state after reboot
You lose network connection	Local work continues unaffected
You clear site data	Nothing—the workspace is gone without an export

The last row is the one people discover painfully. Everything above it involves the browser keeping what it stored; the last row involves you or your software deliberately discarding it. Different failure class, different defense.

Where the data physically lives

Inside the browser profile directory on your disk, under a folder structure keyed by origin. You never need to touch it—and generally should not—but knowing its nature answers practical questions:

• Switching to a different browser leaves the data behind, because Chrome’s profile is not Firefox’s.
• Syncing browser bookmarks across machines does not necessarily carry IndexedDB content; sync services cherry-pick what they replicate.
• Uninstalling a browser with “delete my data” checked removes it permanently.

The four ways people accidentally lose local work

Private or incognito windows. These sessions run with temporary storage that is discarded when the window closes. Anything written during the session evaporates with it. For important work, use a normal window.

Clearing browsing data. The “cookies and site data” option in a browser’s cleanup dialog includes local databases. A broad “clear everything” sweep takes every origin with it; a targeted per-site cleanup takes only the site you name.

Changing profiles or devices. Local means local to that profile on that machine. A new laptop starts empty unless you exported files and brought them along.

Storage cleanup and resets. Under disk pressure, browsers may reclaim space from origins they consider eligible, and a full browser reset removes site data outright. Eviction policies differ by browser and version—the safe assumption is that unexported local data is always one bad day away from gone.

When storage runs short

Browsers grant each origin a generous share of free disk space rather than a fixed number, which is why quota problems are rare in normal use. They are not impossible, though, and they surface in two distinct ways.

A quota error happens when an app tries to write more than the browser will currently allow—usually on a nearly full disk or after importing very large files. Well-built tools catch this and tell you plainly; the practical response is freeing disk space and exporting your work before continuing.

Eviction is quieter. When a device runs critically low on space, browsers may reclaim data from origins they judge least-used, and site data can be among the casualties. Recent browsers increasingly spare sites you have installed as apps or explicitly bookmarked, but heuristics vary by browser and version. Treat eviction the way you treat housekeeping by someone else: rare, well-meaning, and capable of removing things you meant to keep.

Both risks shrink to near-zero with the same habit—periodic exports—which is why the routine below does not distinguish between them.

A safe local-first routine

1. Work normally and let autosave absorb the small accidents—it is good at exactly that.
2. Export a final PDF, .vault backup, or project copy when a meaningful milestone completes.
3. Open the exported file once and confirm it contains what you expect.
4. Store it somewhere you deliberately back up, separate from the browser profile.
5. Keep earlier versions if revision is likely: biology-notes-v3.pdf beats repeatedly overwriting biology-notes.pdf.

Step 3 sounds paranoid until the first time an export is interrupted or a file is moved mid-transfer. Testing takes seconds; discovering a hollow backup months later costs the actual work.

Clearing data without surprises

Before any cleanup session—yours or an IT department’s—download what you would regret losing. If an app offers an export function, that function exists precisely for this moment. A screenshot of the workspace is not a substitute for the real PDF or encrypted vault file; it preserves pixels, not editability.

When troubleshooting a single misbehaving site, prefer clearing data for that site rather than the nuclear “clear all browsing data.” The former is a scalpel; the latter removes every local workspace in the browser at once.

Questions people often ask

Is this the same as cloud sync?

No. Cloud sync copies data to a provider’s servers and distributes it across your devices. IndexedDB stays on one device, under one browser profile. The convenience overlaps; the privacy model is entirely different—one reason local storage pairs naturally with the architecture described in client-side versus cloud PDF security.

Can other websites read what a site stored?

No. Origin isolation prevents it. example.com cannot enumerate, read, or delete what crate.anirone.com wrote, and vice versa.

Does incognito mode keep anything?

Effectively no. Storage created during a private session is discarded when the session ends. Treat private windows as scratch space.

How much can a site store?

Browsers allow substantial amounts—hundreds of megabytes and more—with exact limits varying by browser, available disk space, and version. The engineering comparison of storage options deserves its own article; for users, the relevant fact is simply that quota errors are rare but possible, and exports remain the safety net.

How do I see what a site has stored?

Browser developer tools include a storage panel listing a site’s databases. It is read-mostly territory for curious users, and it makes concrete what “local site data” actually means.

The takeaway

Browser autosave is a quiet, capable safety net built on real database technology running entirely on your machine. It absorbs refreshes, closed tabs, and dead batteries. It cannot survive deliberate deletion, profile moves, or storage pressure—by definition, because those operations target the very place it lives. Export at milestones, verify the exports, and local-first tools become both private and dependable.