Environment Variable Parser

Supported dotenv syntax

Each assignment uses a portable variable name followed by an equals sign and a value. Names must begin with a letter or underscore and may continue with letters, numbers, or underscores. Empty values are valid. Leading and trailing whitespace around the name and equals sign is ignored, blank lines and full-line comments are skipped, and an optional export prefix is accepted.

Unquoted values keep a hash when it is attached to the value, which is useful for URL fragments and literal identifiers. A hash preceded by whitespace begins an inline comment. Single quotes preserve their contents literally. Double quotes support common \n, \r, and \t escapes plus escaped quote or backslash characters. Unclosed quotes and unexpected trailing text produce a line-specific error instead of partial output.

Duplicate values and runtime differences

When a key appears more than once, the last assignment becomes the parsed value and the report identifies the replacement line. That matches a common dotenv convention, but duplicate configuration is often accidental and can vary between loaders. Remove the duplicate or document the intended precedence rather than relying on file order across development, CI, containers, and production.

Dotenv is a family of conventions, not one universal grammar. Some libraries expand ${NAME}, allow multiline quotes, interpret backslashes differently, or load several files with framework-specific precedence. Cryonel deliberately does not expand variables or execute substitutions. Literal parsing makes the result predictable, but the application’s exact loader remains the source of truth.

Choose the right output

JSON preserves the final key-value map for inspection, configuration conversion, or comparison. Shell mode produces one safely single-quoted export command per final value and escapes embedded apostrophes without evaluating the input. The key list helps compare required configuration between environments without copying values. None of these outputs changes the original file automatically.

Redacted JSON masks names commonly associated with passwords, tokens, secrets, private keys, authorization, cookies, and database URLs. This is only a convenience for logs or support messages. A secret named VALUE will not be recognized, while a harmless value with a secret-like name may be hidden. Always inspect the output manually before sharing it.

Handle secrets safely

A local parser reduces network exposure but cannot make copied secrets safe. Avoid committing .env files, screenshots, shell history, CI logs, issue attachments, or chat messages that contain credentials. Store production secrets in the deployment platform’s secret manager, limit access, rotate exposed credentials, and keep separate values for local, staging, and production systems.

Do not use parsed JSON as a public application asset. Browser code cannot keep an embedded secret from users. For structured non-secret data, use the JSON Validator; for generated database statements use SQL Formatter before review.