How to Keep API Keys Secret in a Small Web Tool
If you put an API key inside the JavaScript of a web page, anyone who visits the page can read it. That is the core fact. A key in browser code is not a secret, because the browser has to download the code to run it, and anyone can open the developer tools or view the page source.
The safe approach is to keep the key on a server that you control, and let the web page talk to that server instead. This guide explains why, and what the options are for small projects.
What an API key is
An API key is a long string that identifies you to a service and lets you use it, often with charges attached to your account. It works like a password for programs. If someone else gets your key, they can make requests as you, which may use up your quota, run up charges or access your data, depending on the service.
This matters when you build tools with AI assistants, because the assistant will happily write code that calls a service directly from the page with your key pasted in. That works on your computer and is unsafe once published.
Why browser code cannot hold secrets
When you publish a page, the browser downloads your HTML and JavaScript. Everything the page can do, a visitor can inspect. Hiding the key with tricks, such as splitting it into pieces or encoding it, only slows down someone curious. It does not make the key private.
Search engines and automated scanners also look for keys in public code. Keys uploaded to public repositories are often found and misused within a short time. Treat any key that has appeared in public code as compromised.
The safe pattern: put a server in between
Instead of the page calling the service directly, the page calls a small piece of code running on a server, and that code adds the key and forwards the request. The key lives only on the server, in a setting called an environment variable, and never reaches the visitor.
You do not need your own server computer. Many static hosts offer small “serverless functions” that run on demand, and separate services provide similar proxies. Ask your assistant: “Show me how to call this API from a serverless function so the key stays on the server, and how to set the key as an environment variable on my host.” Then follow the host’s current documentation, since the details differ.
Add protections even with a proxy
A proxy hides the key but can still be abused if anyone can call it freely. Reduce the risk:
- Set spending limits. Most services let you cap monthly usage or set alerts. Do this first.
- Limit what the key can do. Create a key with only the permissions you need.
- Limit requests. Ask your assistant to add simple rate limiting to the function.
- Restrict by origin where supported, so requests only count if they come from your site.
- Monitor usage. Look at the service’s usage page regularly, especially after publishing.
If a key is exposed
Act quickly:
- Revoke or delete the key in the service’s dashboard.
- Create a new key.
- Replace it in your server settings, not in your page code.
- Check usage and billing for unexpected activity.
- If it was in a public repository, remember that the old key remains visible in history, so revoking is essential.
Removing the key from a file and uploading a new version does not undo the exposure. Assume anyone could have copied it.
What to do with tools that need no secret
Many useful services need no key, or provide keys designed to be public with restrictions attached, such as certain map or analytics identifiers. The documentation will say whether a key is safe for browser use. When in doubt, treat it as a secret. A tool that only does calculations in the browser needs no keys at all, and that is the simplest and safest design.
Keep keys out of your files and chats
Do not paste keys into chat messages with an AI assistant. Use a placeholder like YOUR_API_KEY in code you share, and fill in the real value in your server settings. Do not commit keys to repositories, even private ones, and do not store them in files inside the folder you upload to a static host.
Keep a record of where each key is used so you know what to rotate if something goes wrong. A short list in your notes file, without the key values themselves, is enough.
Know when to ask for help
If your tool handles other people’s data or payments, get a review from someone with security experience before you publish. A general guide cannot cover your situation. For a small hobby tool with a spending cap, the steps above give you a sensible baseline.
A realistic example
Suppose your tool sends text to an AI service and shows the answer. The wrong design puts the key in the page and calls the service directly. The better design has the page send the text to a small function on your host. The function holds the key, calls the service, and sends back only the answer.
You can ask your assistant to write both parts, and to add a limit so that one visitor cannot send hundreds of requests a minute. Then test it: open the page’s source and the network tab in developer tools, and confirm that the key appears nowhere. If you can find it, so can everyone else. This check takes two minutes and is worth doing every time you publish a tool that uses a key.
Next steps
Audit one project today. Search your files for the words key, token and secret. If you find any, move them to server settings, revoke the old ones, and set a spending limit with the service. Then write the plan, in one paragraph, in your notes file, so you follow the same routine next time.