Only values you are happy for every visitor to read are safe behind the NEXT_PUBLIC prefix. Next.js copies those variables into the JavaScript bundle at build time. Publishable payment keys and analytics IDs fit. Secret API keys, webhook signing secrets and admin tokens never do.
What the prefix does
The Next.js environment variables guide says you can bundle variables for the browser by prefixing them with NEXT_PUBLIC. It explains that Next.js can inline the value at build time into the JavaScript bundle delivered to the client, replacing references to the variable with a hard coded value. The same page warns that you almost never want to commit your env files to the repository.
Two consequences follow. First, anyone can read the value by opening the bundle. Second, rotating the value means rebuilding, because it is baked in.
A sorting table for common store settings
| Setting | Prefix allowed? | Reason |
|---|---|---|
| Publishable payment key | Yes | Designed to be embedded in client code |
| Analytics or pixel ID | Yes | Already visible in page requests |
| Public catalog API token | Yes, with narrow scopes | Meant for browsers |
| Secret or restricted payment key | No | Grants server side actions |
| Webhook signing secret | No | Lets an attacker forge events |
| Admin API token | No | Full back office access |
| Database URL | No | Direct data access |
Steps to audit a project
- List every variable that starts with NEXT_PUBLIC in your env files, your hosting dashboard and your CI settings.
- For each, ask whether you would paste the value on your homepage. If not, rename it and move its use to server code.
- Build the project and search the output folder for a few characters of each server only secret. A hit means it leaked.
- Rotate anything that leaked, and check logs for use of the old value.
- Add a CI check that fails the build if a secret pattern appears in the output.
The mistake to watch for
The common error is not a malicious change. It is a developer who gets an error in the browser, adds the prefix to make a variable available, and ships. A review rule helps: any new variable with the prefix needs a named reason in the pull request.
Try it yourself
Click through it at your own pace, or open it full screen. Watch for how findings point to the exact file and line.
Safeguard scans code and dependencies in pull requests, and the free scan at gold.safeguard.sh/scan is a quick way to see what a repository shows.
Quick check
Does the prefix encrypt the value?
No. It inlines the value into the client bundle, so anyone can read it.
If a secret leaked through the prefix, is a redeploy enough?
No. Rotate the secret first, then rebuild. The old value may already be cached or copied.
Sources
Last reviewed: 19 October 2026.
