What should an offline web app do when the browser evicts its saved drafts?

Browser-saved drafts should be treated as recoverable cache unless you have a stronger durability path. IndexedDB is the right local store for offline drafts, but it is still browser-managed storage, so your app needs explicit states such as local-only, persistent-local when granted, and synchronized. Build the UX around that contract: detect storage pressure, handle failed writes, offer export or sync, and never imply that offline drafts are permanent by default.

What promise should the app make?

Make a promise your implementation can keep. The Storage Standard says browser storage can be lost as device storage fills up, and distinguishes persistent storage that “cannot be cleared without consent by the user.” That means your product copy should not say drafts are safely stored forever just because they are in IndexedDB.

A useful contract is:

• Local-only draft: available offline, may be removed by the browser or user.
• Persistent local draft: local draft with persistent storage granted where supported.
• Synchronized draft: copied to your server when connectivity returns; this is the real durability boundary.

That framing keeps the engineering model honest. IndexedDB exists so user agents can “store large numbers of objects locally” for offline applications, but the spec does not upgrade local storage into a guaranteed backup system.

How should the app detect and handle failure?

Do not stop at a preflight quota check. The enforced ordering boundary is the write itself: even if navigator.storage.estimate() looks healthy, the actual IndexedDB transaction can still fail, so the save path must treat commit success as the point where the draft is stored.

A practical flow:

1. On app start, check navigator.storage.persisted().
2. Before large attachments or form sections, use navigator.storage.estimate() to warn about low space.
3. When the user reaches a meaningful milestone, explain why durable local storage matters and request navigator.storage.persist().
4. On every save, wait for IndexedDB transaction completion before showing “Saved offline.”
5. If the write fails or a previously listed draft is missing, switch the UI to a recovery state: explain what happened, keep the in-memory form data if available, and offer export.

What does good recovery UX look like?

Consider a field inspection app used with no signal. An inspector writes notes, adds photos, and sees “Saved on this device.” After several large photos, the next IndexedDB write aborts. The app should immediately stop claiming the draft is safe, keep the current form in memory, show “Device storage is full; this draft was not fully saved locally,” and offer three actions: remove unsent photos, export the draft to a file, or retry after freeing space.

If the browser later evicts an older local-only draft, the draft list should show it as unavailable rather than silently disappearing from the user’s mental model. If you maintain a sync log, tell the user whether the last server copy exists. That distinction matters more than blaming the browser.

Should you rely on persistence requests or on sync?

Use both, but treat sync as the stronger guarantee. Persistence requests are valuable because the standard provides a path to storage that cannot be cleared without user consent, but support and grant decisions remain browser-controlled. Sync gives you an application-level durability boundary you can explain clearly.

Q: Can a web app guarantee offline drafts will never be deleted?
No. It can improve odds with persistent storage and better quota handling, but only synchronized copies give you a durable system-level backup.

Q: Should users be told to clear browser data?
Only as a last resort. Prefer targeted guidance: free device space, remove large local attachments, export the draft, then retry the save.

Next step: write down your draft durability states in the product spec, then update the save code so UI success appears only after the IndexedDB write actually commits.

Reviewed: 2026-09-05