Why do CRA and Vite require a prefix on every exposed variable?

Both tools only inline environment variables into the client bundle at build time if the name starts with their required prefix (REACT_APP_ for Create React App, VITE_ for Vite); this is a deliberate safety measure so a plain, unprefixed secret in your shell or CI environment (like a database password) never accidentally ends up in code shipped to the browser.

Why is Next.js different, only some variables get NEXT_PUBLIC_?

Next.js runs both server and client code from the same project, so it distinguishes them: variables without a prefix stay server-only (safe for secrets, read in Server Components/Route Handlers), while only variables explicitly prefixed NEXT_PUBLIC_ are inlined into client-side JavaScript and become readable in the browser.

Why validate environment variables with Zod at all?

Without validation, a missing or misspelled environment variable often fails silently, `process.env.SOME_VAR` is simply `undefined` and the app may not fail until that code path runs in production. Parsing all expected variables through a Zod schema at startup fails fast with a clear error listing exactly which variable is missing or invalid.

Does entering a variable name that already includes the prefix cause double-prefixing?

No, the tool checks whether your entered name already starts with the framework's required prefix and leaves it as-is if so, only prepending the prefix when it's actually missing.

React .env Generator - CRA, Vite & Next.js Prefixes + Zod

Overview

Introduction

Every React-based toolchain, Create React App, Vite, and Next.js, has its own rule for which environment variables get exposed to browser code, and getting the prefix wrong either leaks a variable that should have stayed server-only or silently produces `undefined` in the client bundle.

This tool generates a .env file with the correct prefix for your chosen framework, plus a Zod schema that validates those same variables exist and are non-empty at startup.

What Is React Environment Variables Generator?

A .env and Zod-schema generator covering Create React App (REACT_APP_ prefix, all variables client-exposed), Vite (VITE_ prefix, all variables client-exposed), and Next.js (NEXT_PUBLIC_ prefix only for variables you explicitly mark client-exposed, server variables stay unprefixed).

The Zod schema output validates every generated variable is present and non-empty, and parses `process.env` (or `import.meta.env` for Vite) into a typed, safe-to-import `env` object.

How React Environment Variables Generator Works

Each variable name is uppercased and checked against the framework's required prefix; if it's missing, the prefix is prepended (for Next.js, only when you've marked that variable as client-exposed, otherwise it stays unprefixed for server-only use).

The same resolved variable names are used to build both the .env file (KEY=value lines) and a Zod object schema with a `.min(1, ...)` check per field, so both outputs always describe the exact same variable set.

When To Use React Environment Variables Generator

Use it when adding a new environment variable to a React app and you're unsure whether/how it needs to be prefixed for your specific build tool to expose it to client code.

It's also useful for bootstrapping environment-variable validation on a project that currently reads `process.env` directly with no startup checks.

Often used alongside Next.js Config Generator, Vite Config Generator and Vue Config Generator (Vue 3 / Vue 2).

Features

Advantages

Applies the correct prefix rule per framework automatically, avoiding the common mistake of using the wrong tool's prefix convention (e.g. VITE_ in a Next.js app, where it has no special meaning).
Distinguishes server-only from client-exposed variables for Next.js specifically, helping avoid accidentally shipping a secret to the browser.
Generates a matching Zod schema so a missing or empty variable fails loudly at startup instead of surfacing as a mysterious `undefined` deep in application code.

Limitations

Doesn't detect or warn about a variable name that looks like it should be secret (e.g. containing "SECRET" or "KEY") being marked client-exposed; that judgment call is left to you.
The generated Zod schema only checks presence/non-emptiness; it doesn't validate more specific shapes (URLs, numbers, enums) unless you extend the schema afterward.

Examples

A Next.js app with one public and one server-only variable

Input

framework: nextjs, vars: [{name: "API_URL", exposeToClient: true}, {name: "DATABASE_URL", exposeToClient: false}]

Output

.env:
NEXT_PUBLIC_API_URL=https://api.example.com
DATABASE_URL=postgres://user:pass@host/db

Zod schema validates both NEXT_PUBLIC_API_URL and DATABASE_URL as required strings.

Only the variable marked exposeToClient gets the NEXT_PUBLIC_ prefix; the database URL stays unprefixed and server-only.

Best Practices & Notes

Best Practices

Never mark a secret (API key, database credential, signing secret) as client-exposed, since anything prefixed for client exposure ends up readable in browser devtools and shipped source.
Run the generated Zod schema's `.parse()` call as early as possible in the app's startup path, so a missing variable fails the build or boot process immediately rather than at first use.
Keep a checked-in `.env.example` with placeholder values (not the real .env, which should stay gitignored) so new contributors know exactly which variables to set.

Developer Notes

Vite exposes variables via the special `import.meta.env` object rather than Node's `process.env` (since Vite's dev/build pipeline statically replaces these references), so the generated Zod schema's parse call targets `import.meta.env` specifically for the Vite framework option, while CRA and Next.js both read `process.env` since they run through Node-based tooling at build/runtime. The name-prefix check (skipping re-prefixing if the entered name already starts with the required prefix) avoids producing a doubled prefix like VITE_VITE_API_URL when a user pastes in an already-prefixed name.

React Environment Variables Generator Use Cases

Adding a new environment variable to a React app with the correct client-exposure prefix for the build tool in use
Bootstrapping startup-time environment variable validation with Zod on a project with none
Auditing which variables are client-exposed vs. server-only in a Next.js app

Common Mistakes

Using Vite's VITE_ prefix (or CRA's REACT_APP_) in a Next.js project, where it has no special meaning and the variable simply won't be exposed to client code.
Marking a secret value as client-exposed in Next.js, shipping it in the browser bundle where anyone can read it from devtools or view-source.

Tips

Use the Next.js Config Generator alongside this if you're also configuring image domains or headers for the same project.

React Environment Variables Generator