Storing an API key in the browser safely

Keeping your API key in the browser gets called a security heresy by some and a reasonable practice by others. Both answers circulate and both are right, because they describe different cases. A publisher's key embedded in a public page is a mistake. Your own key, kept in your own browser for your own use, is a defensible setup as long as you take a few precautions. The line between the two cases is easy to draw.

The debate deserves better than slogans. It shapes the choice of a BYOK tool, where the question of where your key lives separates serious architectures from the rest. The short answer comes first, followed by the nuances and then the precautions. By the end you'll know which questions to put to any tool that asks for your key.

01Key takeaways

• Everything depends on who uses the key. A key served to visitors is never acceptable, while your own key on your own machine is fine with precautions.
• The forbidden case is a shared key embedded in the code of a public page, readable by anyone who opens the inspector.
• The legitimate case is BYOK, with your key stored in your browser and never sent to the tool's server.
• The real risks sit on your computer. They are script injection, overly curious extensions and shared machines.
• The countermeasures come down to four habits, spending cap included.

02The short answer depends on who uses the key

The rule in security guides says never to put a key on the client side. It targets one precise case, the developer who embeds THEIR key in an application served to other people. There, every visitor receives the secret along with the page. The browser inspector reveals it in two clicks and the publisher's bill belongs to the first curious visitor. That rule is absolute and nobody disputes it.

BYOK reverses the roles. The user brings their own key and keeps it on their own computer. The tool serves that key to nobody because the key never even passes through it. AI without a subscription rests on this setup. The security question then changes nature, since it becomes a matter of your browser's health instead of public exposure.

03The forbidden case is a publisher's key in the page

To put it bluntly, a key that has to serve several users lives on a server. It sits behind a front end that relays requests without ever exposing the secret. Embedding that shared key in the page's code amounts to giving it away. The bots that crawl the web will find it before the end of the week. The inspector shows it to anyone right now.

This case explains the bad reputation of browser storage, yet it simply doesn't describe BYOK. Confusing the two is like banning personal key rings because you shouldn't leave the building's master key hanging in the lobby. The two situations share a word and very little else, so they call for opposite answers.

04The legitimate case is your key, your browser and your use

When the key belongs to you and serves only you, keeping it in your browser has strengths that a server detour doesn't offer. It never passes through the tool's infrastructure. It sits in no central database that an attacker could harvest. It can be replaced in ten seconds with a simple paste. Your data in a BYOK setup extends the same reasoning to everything else that travels.

OpenTahr uses this architecture and the account is free. The key is stored locally in your browser, so our servers never see its value. A service that holds no keys has no keys to lose. That sentence sums up the choice better than any sales pitch could. It is also the first thing to check in any tool.

05localStorage, sessionStorage or memory, where exactly

Storage	Lifetime	Good use for a key
localStorage	persistent, per site and per protocol	everyday convenience, ideally encrypted
sessionStorage	as long as the tab stays open	shared computer or one-off use
memory (not persisted)	as long as the page stays open	maximum caution, key pasted again at each visit

The MDN reference documents these behaviors. Local storage persists per origin, keeps HTTP apart from HTTPS and offers a few megabytes, far more than a key needs. The choice is a slider between convenience and caution. A careful tool can also encrypt the value before storing it, which mainly protects against casual reading. It should also offer one-click deletion. For the technical details of the mechanism itself, the MDN documentation is the authority and needs no paraphrase.

06The real risks on your computer and how to counter them

The first risk is script injection, since malicious code running in the page can read whatever the page can read. The countermeasure belongs first to the tool, which has to protect itself against injected content. It then belongs to you, because you don't install dubious extensions. Those extensions are the second risk, since an overly permissive extension sees everything your browser sees.

The third risk is the shared machine. On a family or public computer, persistent storage leaves the key available to the next session. The simple answer is session storage or deleting the key when you leave. The deeper answer is locking your user session, which protects the key along with everything else. For the worst case, reacting when a key escapes takes only an hour.

07Compare architectures before choosing a tool

The question to ask any tool that wants your key is simply where the key lives. Three answers exist. The most common is on the service's servers, which is convenient but puts your key in a central database whose security is entirely out of your hands. The second is in your browser, where the key stays with you and the tool only reaches it at the moment of the call, from your computer. The third is in memory only, which is maximum caution at the price of pasting the key again at every session.

None of these answers is shameful in itself. What matters is that the tool answers clearly and that its answer matches your own standards. Silence or vagueness on this simple question is a signal in its own right. A service that can't say where its customers' keys live has probably not done the work of protecting them.

08Four precautions that keep the setup healthy

1. The spending cap at the provider. Whatever happens to the browser, the budget has a limit.
2. A key dedicated to the tool and named for it, never the key you use elsewhere. Revocation then stays surgical.
3. An up-to-date computer with a short list of trusted extensions. The browser's health is the health of everything it holds.
4. A regular cleanup. The eight protection habits turn it into a five-minute routine.

In a team, the setup works without any sharing at all. Each member keeps their key in their own browser, while organizing keys across a team handles the rest. To get started, getting a key in five minutes gives the step-by-step instructions for each provider, so you can be up and running the same day.

09Frequently asked questions

Can I store an API key in localStorage?

Your own key, for your own use, yes. That's the BYOK setup, ideally with an encrypted value and a spending cap as a safety net. A publisher's key meant to serve visitors, never. That key belongs on a server, behind a front end that doesn't expose it to anyone.

Is browser storage vulnerable?

It shares the risks of your computer. A malicious script injected into the page or an overly permissive extension can read what the page reads. The countermeasures are well known, with a tool that sanitizes its content, trusted extensions, an up-to-date machine and a locked session. The spending cap limits whatever risk is left.

localStorage or sessionStorage for an API key?

Use localStorage for convenience on your personal machine, since the key survives restarts. Use sessionStorage on a shared computer, since everything disappears when the tab closes. The MDN reference details both behaviors. A good tool lets you choose or deletes the key on request.

Why doesn't a BYOK tool keep the key on its servers?

A service that centralizes thousands of keys becomes a target and a single point of failure, so its leak would be a leak for all its customers. A key that stays in each person's browser removes that attack surface. The tool has nothing to protect because it holds nothing.

Transparency note. The storage behaviors cited (persistence per origin and per protocol, capacity of a few megabytes) come from the MDN documentation listed in the sources, checked on June 13, 2026. The distinction between a publisher's key and a personal key is the backbone of the reasoning on purpose, since the two cases call for opposite answers. No provider mentioned pays us anything.

10Sources

1. MDN, official localStorage reference
2. MDN, official sessionStorage reference
3. OpenAI, official help on API key safety best practices