Local Browser Storage for AI Chats
IndexedDB and OPFS Explained

Published June 18, 2026 · Updated August 19, 2026

When most people think about AI privacy, they think about one thing: which model reads my prompt? It's a fair worry, and it gets nearly all the attention. But it's only half the story. The other half is quieter and, for sensitive work, often more important: after the answer comes back, where does the conversation actually live?

Every chat you have with an AI tool leaves a residue: a transcript of what you asked, what you uploaded, and what you got back. With most mainstream chatbots, that residue is kept for you by default, in a cloud account tied to your identity, in a sidebar you can scroll back through months later. That's convenient. It's also a permanent, centralized record of your thinking, sitting on someone else's servers. This article is about a different default, one where your long-term chat history stays in your own browser instead. To get there, we need to understand two browser technologies most people have never heard of: IndexedDB and OPFS. Secret Chat is built on both, and we will come back to how.

What "local browser storage" means for AI chats

Let us define the term carefully, because it's easy to read more into it than it means.

"local browser storage" means the data is saved on your device, by your browser, rather than in an app's server database. Your chat history, in this model, is a set of records sitting on your laptop or phone, not a row in a company's cloud table.

Now the important caveats, because this is exactly where marketing tends to overreach:

• It does not mean the AI runs on your device. The model still lives with a provider, and your prompt still has to travel there to be answered. Local storage isn't local inference.
• It does not automatically mean encryption. Whether the stored data is encrypted at rest depends on your operating system and device settings, not on the storage technology itself.
• It does not mean the data is permanent or untouchable. Browsers can clear it, and so can you.

What it does mean is the thing that matters most: the app avoids keeping a long-term, server-side archive of your conversations. The single biggest misunderstanding to clear up before going further is this — local storage is not local inference. The model still sees your prompt. What changes is where the history of that exchange ends up living afterward.

IndexedDB explained: the browser database for chat history

Browsers have had simple storage for years, in a feature called localStorage — except it can only hold small bits of text, like a saved theme setting. It's the digital equivalent of a sticky note. Useful, but you wouldn't run a filing system on sticky notes.

IndexedDB is the filing cabinet. It's a browser API designed to store significant amounts of structured data on the client side, including files and binary objects, with support for indexed searches across that data. Instead of one flat string, it can hold organized records: each message, who sent it, when, which model answered, which tool was used, and which conversation it belongs to. Because it can index that data, an app can search and sort your history quickly (find a conversation from last month, jump to a particular thread) without ever asking a server.

This structure is exactly why IndexedDB fits chat history so well. A conversation isn't one blob of text; it's a sequence of related records — prompts, responses, timestamps, model labels, conversation IDs, the order they happened in. A real database handles that gracefully. A sticky note can't.

IndexedDB also follows the browser's same-origin policy. In plain terms: the data one website stores is walled off from every other website. A different site can't reach into your chat app's IndexedDB and read your conversations. Read that boundary precisely, though: it's isolation by origin (scheme, host and port together), and it keeps out other origins, not code already running with your chat app's own authority. A cross-site scripting flaw, a compromised first-party script or a privileged browser extension is inside the wall, not outside it. That isolation is a meaningful privacy boundary, built into the browser itself.

This is the technology Secret Chat uses to store your text conversations, according to its published architecture; your messages and their metadata live in your browser's own database, organized so you can search and revisit them, but not parked in a central account history.

OPFS explained: the browser file system for uploads

Text messages are one kind of data. The files you upload (a contract as a PDF, a screenshot, a scanned document) are another thing entirely. They're larger, they're binary, and treating them like ordinary database rows is clumsy. They deserve a proper file system, and that's what OPFS provides.

OPFS, the Origin Private File System — is part of the browser's File System API. It gives a page a file system that's private to that page's origin: a sandboxed storage area belonging to one website and not shared with others. Crucially, it's not visible to you the way your normal files are. You won't find these files sitting in your Documents folder or Downloads; they live inside the browser's private storage for that site. It's designed for performant file access, including low-level, byte-by-byte writing, which makes it well suited to handling heavier file-like data efficiently.

The division of labor is clean: IndexedDB is the right place for structured chat records; OPFS is the right place for the heavier file-like data those chats reference, the PDFs and images you upload. Secret Chat uses OPFS for exactly that, storing uploaded images and PDFs in this private, origin-scoped file system rather than shipping them off to a server library, per its stated design.

IndexedDB vs OPFS vs localStorage

Four storage approaches, side by side, so the roles are clear:

A fair note on localStorage: it isn't "insecure" in itself. It's simply limited — small, text-only, and not built for large or structured archives. It's the right tool for remembering your theme, the wrong tool for holding a year of conversations. And the cloud database row at the bottom isn't evil either; it's what makes your history follow you from phone to laptop. The trade-off is the whole point: that convenience is bought with a centralized copy of your conversations.

Why local browser storage matters for private AI chats

Here's why this architecture is worth caring about, stated plainly and without overclaiming.

1. No central chat archive to breach, subpoena, or mine. If an app doesn't keep your conversation history in its own server database, there's simply less of you sitting in one place. A breach of the app can't leak conversations the app never stored. There's no centralized trove to hand over in response to a legal request, and nothing to quietly analyze for behavioral signals. You can't lose what was never collected.

2. Real user control. Because the history lives in your browser, you hold the controls. You can delete it, and where the app supports it, export it and import it elsewhere. You decide which device the archive lives on. Deletion isn't a request you file with a vendor and hope is honored; it's something you do directly.

3. Less profiling. When an app also avoids identity-heavy accounts, keeping history local means far less behavioral data gets stitched to a profile of you. Your conversations aren't feeding a long-term portrait of your interests, worries, and work.

This is the shape of Secret Chat's stated privacy model: local browser storage for your history, minimal email-only registration rather than a full identity, gateway routing that protects your IP address, removal of file metadata, deletion requests sent to providers where supported, and per-session PDF privacy reports. The local-storage piece is the foundation the rest is built on.

What local browser storage does not protect against

This section isn't optional. Skipping it would turn an honest argument into marketing, and the whole point of this approach is that it survives scrutiny. So, clearly, what local storage does not do:

• It does not hide your prompt from the model provider. To answer you, the selected AI still receives your prompt during inference. That's true of every cloud AI tool, and local storage doesn't change it.
• It does not protect a compromised device. Malware running as you, or anyone with your unlocked session, reaches browser-stored data like anything else on the machine. Full-disk encryption is real protection, but for a narrower case: a device that's powered off or locked when it's taken.
• It does not magically encrypt your data against every local attacker. Encryption at rest depends on your OS and device, not on the storage API.
• It does not guarantee your data survives. Browser cleanup, private-browsing sessions, storage pressure, or your own "clear site data" click can all remove it.
• It is not, by itself, regulatory compliance. Local storage doesn't equal HIPAA or GDPR compliance. Compliance depends on your full workflow, contracts, the provider's handling, your jurisdiction, and the type of data involved.

The honest framing is the credible one: local browser storage removes one of the largest and most permanent privacy risks in AI chat, the vendor-held conversation archive. It doesn't remove all risk, and any tool that claims it does is overselling.

Browser storage limits: what users should know

Storing data in the browser comes with real-world constraints, and they're worth understanding before you rely on it.

Browser storage is governed by quotas, and the exact rules vary from browser to browser. Both IndexedDB and OPFS are managed by the browser's storage system and share in those limits. Under storage pressure (when a device is running low on space) browsers can evict data to free room. By default this storage is treated as "best-effort," meaning the browser doesn't promise to keep it forever; an app can request more durable, persistent storage, but that's a request, not a guarantee.

Safari has a rule that matters more than storage pressure, and it surprises people. With tracking prevention on, WebKit proactively deletes script-writable storage (IndexedDB and OPFS included) after seven days of Safari use without you interacting with the site. Not seven days of disk pressure; seven days of not visiting. For a local-first chat history that's the single most likely way to lose it. Two things blunt it: installing the site to the Home Screen as a web app exempts it, and using the app regularly resets the clock. If you're on Safari or an iPhone and you care about the archive, export it.

Asking for persistence helps, but only against pressure. A site can call navigator.storage.persist(), which requests that the origin be marked persistent and returns whether it was granted — Chromium and Safari decide by heuristic, Firefox may prompt. Granted persistence protects against automatic eviction under storage pressure. It never protects against you clearing site data, and it doesn't exempt you from Safari's seven-day rule.

Rough capacity, so you can judge for yourself. Per-origin quotas are generous but calculated rather than promised: Firefox allows the lesser of about 10% of disk or a 10 GiB group cap for best-effort storage (50% of disk, capped at 8 TiB, once persistent); Chromium allows roughly 60% of total disk; Safari around 60% for browser apps and roughly 15% inside embedded web views. IndexedDB and OPFS draw on the same origin quota rather than having separate ones. For the full numbers and the arithmetic of what actually fits (messages, images, and what happens at the ceiling) see our deep dive into browser storage limits for chat history.

Private or incognito browsing changes the picture entirely. Those sessions typically use different quotas and usually delete stored data when the private session ends, which is great if you want a clean slate, and a problem if you expected your history to still be there tomorrow.

The practical takeaway: if a conversation matters to you long-term, treat your browser as one device, not as a vault. Use the app's export feature where it exists, and keep a copy; our guide to exporting, backing up and migrating local chat history safely covers how to store that copy without undoing the privacy you came for. Admitting this trade-off isn't a weakness of the model; it's what makes it trustworthy.

Is OPFS safe?

OPFS is sandboxed by origin and isn't exposed like ordinary files on your disk, which makes it a sensible place to keep uploads. But no browser API is risk-free, and it would be dishonest to pretend otherwise.

In 2026, security researchers published work, the FROST paper, describing an OPFS-based SSD timing side-channel attack: under specific conditions, the way OPFS writes to a solid-state drive could be measured to leak information. This isn't a reason to declare "OPFS is unsafe," and it doesn't describe everyday risk for a typical user. It's a reason to be honest: serious privacy architecture has to acknowledge that browser-level mechanisms carry their own attack surface, and that researchers will keep probing them. A tool that talks openly about findings like FROST is more trustworthy than one that pretends the browser is a sealed box.

How Secret Chat uses IndexedDB and OPFS

Pulling the pieces together, here's how Secret Chat applies all of this, according to its published description:

• Text conversations live in IndexedDB — your messages, timestamps, the model used, and conversation structure, stored in your browser's own database so you can search and revisit them.
• Uploaded images and PDFs live in OPFS — held in the browser's private, origin-scoped file system rather than uploaded to a server file library.
• No server-side copy of your conversations is claimed. The long-term archive is on your device, not in Secret Chat's database.
• Prompts still route through model providers. To answer you, your message goes to the selected model; that part isn't hidden, and not pretended away. On the AI Council, where several models from different companies answer the same question at once, it goes to every model on the panel and to the referee that compares them, so a council widens where your text travels even though the storage picture below is unchanged.
• A finished council is stored like any other chat. Every panel answer and the referee's disagreement table go into the same IndexedDB record as an ordinary conversation, so the comparison you paid for stays on your device, is searchable later, and travels in an export. Nothing about a multi-model turn creates a server-side copy that a single-model turn wouldn't.

The distinction worth holding onto is this:

The privacy value is in the architecture around the model — local history, gateway routing, metadata handling, and deletion reports, not in any false claim that the model never sees your words.

Who benefits most from this architecture?

This default helps anyone, but it matters most for people whose conversations carry weight:

• Lawyers drafting and reasoning through matters without leaving long-term chat archives in a consumer AI account.
• Journalists working with sensitive source material and unpublished reporting.
• Consultants handling client documents and confidential briefs.
• Therapists and compliance staff dealing with information that shouldn't accumulate in a vendor's cloud.
• Researchers drafting unpublished work they aren't ready to expose.
• Founders thinking through confidential strategy.
• Privacy-conscious individuals who simply don't want a permanent cloud transcript of everything they have ever asked an AI.

None of this is a promise of regulatory compliance; that depends on far more than where files sit. It's a meaningfully better privacy posture than ordinary cloud chat history, for people who have a reason to care.

Final takeaway

Cloud-stored AI chat history is convenient. It also creates a permanent data trail: a centralized record of your questions, your documents, and your thinking, held by someone else. Local browser storage changes the default:

That's the shift worth understanding. The model still does the thinking, and your prompt still travels to it, but the long-term archive belongs to you, in your browser, rather than to a vendor's database. For sensitive work, that single change in where history lives is one of the most practical privacy decisions you can make.

Start a private AI chat with Secret Chat and keep your conversation history where it belongs, in your browser. If you also want to understand the storage question from the mainstream side, see whether ChatGPT stores your conversations.

Frequently Asked Questions

1. Where are my AI chats stored when an app uses local browser storage?

   On your own device, inside your browser. Text conversations are kept in IndexedDB, the browser's structured database, and uploaded files like images and PDFs are kept in OPFS, a private file system scoped to that one site. They aren't parked in a server-side account archive.

2. Does local browser storage mean the AI runs on my device?

   No. This is the most common confusion. Local storage means your history is kept locally, but the AI model still lives with its provider, and your prompt still travels there to be answered. Local storage isn't local inference.

3. What is the difference between IndexedDB and localStorage?

   localStorage holds small text-only values, like a saved setting, a sticky note. IndexedDB is a full client-side database that stores structured records and files and supports indexed search, a filing cabinet. Chat history needs the filing cabinet.

4. Is IndexedDB or OPFS encrypted?

   Not automatically by the storage technology itself. Whether the data is encrypted at rest depends on your operating system and device settings. Don't assume browser storage is encrypted just because it's local.

5. Can browser-stored AI chats be lost?

   Yes, and the likeliest cause isn't what people expect. Safari's tracking prevention deletes script-writable storage after seven days of Safari use without visiting the site, unless it has been installed to the Home Screen. Beyond that, browser storage is subject to quotas and can be evicted under storage pressure, the exact rules vary by browser, and private or incognito sessions usually delete stored data when they end. If a conversation matters long-term, export and back it up where the app supports it.

6. Is OPFS safe to store sensitive uploads?

   OPFS is sandboxed by origin and not visible like normal files, which is a reasonable safeguard, but no browser API is risk-free. In 2026 the FROST research described an OPFS-based SSD timing side-channel under specific conditions. The honest takeaway is that local storage reduces centralized risk but doesn't eliminate all browser-level risk.

7. How does Secret Chat use this?

   According to its published architecture, Secret Chat stores text conversations in IndexedDB and uploaded images and PDFs in OPFS, in your browser, with no server-side conversation copy claimed. Prompts still route to the selected model for processing; it's a private AI chat gateway with local history, not a local LLM.

Sources

• MDN: IndexedDB API
• MDN: Origin Private File System
• MDN: Storage quotas and eviction criteria
• FROST: an OPFS-based SSD timing side-channel (2026 research paper)