By · Updated

Config Generator

Settings From One Key = Value List, With Warnings for Likely Secrets

No ratings yet

OneTask is free, with no sign-up, and built by one person.
If this tool saved you time, a coffee helps keep new ones coming.

How the Config Generator works

This config generator writes one set of settings in many formats. Configuration files all say the same thing in different syntaxes. Write your settings once as plain key = value lines, group them under [section] headers if you like, and switch the output between .env, JSON, YAML, TOML and INI. Numbers, booleans and lists are typed correctly for each format, .env keys are upper-cased, and the download button gives you the file with the right name.

Config generator: one model, many syntaxes

Every runtime has its favourite config format: Docker and twelve-factor apps read .env, Node and browsers like JSON, Kubernetes and CI systems want YAML, Rust and Python packaging use TOML, and a long tail of older tools still read INI. Remembering which one quotes strings, how each nests sections and how booleans are spelt is the kind of detail that costs ten minutes per file. This tool holds those rules so you can concentrate on the values.

Input syntax. One setting per line as key = value (a colon also works as the separator). Keys start with a letter or underscore and may contain letters, digits, underscores, dots and hyphens. Blank lines and lines starting with # are ignored. A line of the form [name] starts a section; everything after it belongs to that section until the next header. Settings before any header are top-level.

Value typing. Bare true and false become booleans, integers and decimals become numbers, and [a, b, c] becomes a list. Everything else is a string. Wrap a value in quotes to force it to stay a string — "8080" stays text where 8080 becomes a number. This typing is applied where the format supports it: JSON, YAML and TOML get real numbers and booleans; .env and INI are string-only formats so values are written plainly and lists are joined with commas.

How sections map. In JSON and YAML a section becomes a nested object. In TOML and INI it becomes a [section] table, which is what those formats were designed around. .env has no nesting, so section names are prefixed onto keys: port under [database] becomes DATABASE_PORT, matching the convention most frameworks use for namespaced environment variables.

Format-specific rules. .env keys are upper-cased with dots and hyphens turned into underscores, and values containing spaces, #, quotes or $ are double-quoted with escapes. YAML strings that could be misread — anything that looks like a number, a boolean, null, yes/no, or contains punctuation — are quoted so version = "1.10" stays the string "1.10" rather than being read back as 1.1. TOML strings are always quoted, since TOML requires it. INI uses ; for the header comment and writes everything as bare text.

Secret detection. Keys containing secret, password, token or key trigger a reminder in the status line to keep the file out of version control. It is a heuristic, not a scanner; treat it as a nudge to add the file to .gitignore.

Limits. One level of nesting is supported: sections containing keys. Deeper structures, arrays of tables, multi-line strings and dates are out of scope — those are rare in application configuration and quickly turn a quick tool into a full editor. For converting existing complex files between JSON and YAML use the dedicated converter on this site.

FAQ

Why did my .env keys change to upper case?

Environment variable names are conventionally upper case with underscores, and many shells and libraries treat them as case-sensitive. The generator normalises to that convention, converting dots and hyphens to underscores, so database.host becomes DATABASE_HOST, which is what most frameworks expect.

How do I keep a number as a string?

Put it in quotes in the input: zip = "01234". Quoted values are always treated as text, which matters for postcodes, phone numbers and version strings that would otherwise lose leading zeros or be parsed as floats.

Can I nest sections more than one level deep?

No. The input format supports top-level keys and one level of [section]. For deeper structures write the JSON or YAML by hand, or generate each section separately and combine. Keeping the grammar tiny is what makes the input quick to type.

Does YAML output quote strings?

Only when it has to. Plain words and paths are written bare for readability; anything that YAML could interpret as another type — numbers, true, no, null, values with colons or leading digits — is quoted so it round-trips as a string.

See also: all Dev Utilities tools, Formatters & Validators, Data & Encoding, Security & Identifiers, SEO, Accessibility, AI.

Related tools