ForHosting KIT · Developer Utilities

Validate an environment variable name

Check whether an environment variable name is portable before it breaks a deployment: DATABASE_URL passes, while a name that starts with a digit or contains a hyphen fails with the exact rule it broke. Free in your browser.

  • Free
  • Runs in your browser
  • No sign-up
  • Your data stays on your device
Use it from WebAPIEmailTelegramApp soon
If you enter
Text
DATABASE_URL
You get
Name
DATABASE_URL
Convention
POSIX

Environment-variable names look simple until a deployment fails because a name begins with a number, contains a hyphen, includes whitespace, or uses a character that a shell cannot treat portably. This validator checks one proposed name against the POSIX portable naming convention: ASCII letters, digits, and underscores are allowed, while the first character must be a letter or underscore. A valid name receives a clear confirmation. An invalid name produces a focused error that identifies the broken rule, making the result useful in editors, setup forms, CI checks, and configuration generators.

What the validator accepts

A portable environment-variable name uses a deliberately small character set. The first character must be an ASCII letter from A through Z or a through z, or an underscore. Every later character may be one of those letters, an underscore, or a digit from 0 through 9.

Names such as DATABASE_URL, HOME, _INTERNAL_FLAG, and API2_TOKEN therefore pass. The validator checks the complete string rather than trying to repair it, normalize it, trim it, or extract a plausible name. That strict behavior matters because silent cleanup can turn the value a user supplied into a different identifier.

Letter case is preserved and significant: PATH and Path are separate names in environments that expose both. The check is intentionally about portable naming syntax, not whether a particular variable exists, is exported, has a value, or is supported by a specific program.

How invalid names are explained

Different mistakes receive different explanations so the caller can correct the actual problem. An empty string fails because there is no initial character. A string beginning with a digit fails the dedicated first-character rule, even though digits are legal later in a name.

A leading hyphen, period, space, or non-ASCII letter fails because the first character is neither an ASCII letter nor an underscore. When the beginning is valid but a later character is not, the error reports that only ASCII letters, digits, and underscores are permitted, then identifies the offending character and its one-based position. The service does not confuse a shell assignment such as NAME=value with a variable name: the equals sign is not part of the name and will be rejected.

Using the check in development workflows

This capability fits wherever names are accepted before configuration reaches a shell or process environment. A deployment form can validate a key as soon as it is submitted and show the precise rule that needs attention. A configuration generator can reject invalid keys before producing a dotenv file, container manifest, service definition, or CI secret mapping.

Linters and repository checks can apply the same deterministic rule to examples and templates, preventing a broken identifier from being copied into several environments. The algorithm performs no network request, reads no process environment, stores no input, and uses no current time or randomness. Remember that syntactic validity does not establish application compatibility.

Individual tools may impose extra conventions, reserve prefixes, treat case differently, or disallow leading underscores even though the portable POSIX form accepted here permits them.

Validate deployment settings

Check variable names in a hosting or container form before saving configuration that a runtime cannot expose reliably.

Protect dotenv generators

Reject malformed keys before generating dotenv content, instead of producing a file that fails only when an application starts.

Add a CI naming check

Verify configuration templates and documented variable names with a deterministic rule during automated repository checks.

What characters are allowed?

ASCII letters, digits, and underscores are allowed. The first character must be an ASCII letter or underscore.

Can an environment-variable name begin with a digit?

No. Digits are allowed only after the first character, so 2FA_TOKEN fails while TOKEN_2FA passes.

Does this check whether the variable exists?

No. It validates only the proposed name. It does not read the environment or inspect whether the variable has been exported or assigned.

Are lowercase names valid?

Yes. Both uppercase and lowercase ASCII letters are valid, and the original letter case is preserved.

Will it fix or trim an invalid name for me?

No. The whole text is checked exactly as typed, without trimming spaces or repairing characters, because silent cleanup could turn your name into a different one. Instead, the error tells you which rule failed and where.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/dev/env-var-name-validate

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/dev/env-var-name-validate \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"DATABASE_URL"}'
{
  "text": "DATABASE_URL"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.env_var_name_validate",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

What the validator accepts

A successful response returns the original name unchanged, a valid flag, and a concise confirmation of the convention applied.

How invalid names are explained

For example, API-KEY fails at its hyphen, while API KEY fails at its embedded space. Typed errors use the invalid_input code, so API clients can distinguish a correctable input problem from an internal failure without parsing transport status text or treating the validation result as an outage.

Using the check in development workflows

The same name therefore produces the same outcome in a browser, an automated test, and an API integration. The price for an API request is $0.002; the browser execution is suitable for quick interactive checks.

Are hyphens or periods allowed?

No. A hyphen, period, space, equals sign, or any other character outside the portable set causes an invalid_input error.

What does an API request cost?

Each API request costs $0.002. The same deterministic check can also run in the browser.

Read the full KIT documentation →