Convert an Env Var List to JSON, TypeScript Union, CSV, or SQL IN

A list of environment variable names is one of those artifacts that lives in five places at once. It starts as a .env.example file, gets copied into a CI secrets dashboard, gets pasted into a Slack thread, ends up half-quoted in a docs table, and finally has to become a typed constant in your code so the compiler stops you from reading proces.env.DATABASE_URL. Each of those destinations wants the same names in a slightly different shape: a JSON array here, a TypeScript union there, a CSV column for the wiki, a SQL IN clause for a one-off audit query.

Retyping the list for each target is where the typos creep in. You drop a comma, you forget a quote, you accidentally rename API_KEY to API_KEYS in one place and not the other. The Environment Variable List Converter exists so you parse the list once and re-emit it in whichever format the next tool needs, with the underlying names left untouched.

What this tool actually outputs

This is not a generic text munger. It reads your variable list with one dedicated parser and then renders that same set of names in six formats:

• One per line — plain, clean, ready to paste back into another .env
• JSON array — for docs generators, config loaders, and test fixtures
• CSV — for a wiki table, a spreadsheet, or a ticket attachment
• Markdown — a fenced or table-ready block for a README or PR description
• SQL IN — a ('DATABASE_URL', 'API_KEY', ...) clause for audit queries
• TypeScript union — 'DATABASE_URL' | 'API_KEY' for a typed config accessor

Switching format never changes the values. It only changes the punctuation around them. That is the whole point: the converter is the single source of truth for the names, and every output is a faithful re-render of that one list.

Alongside the format switch, you can keep unique rows only, preserve invalid rows so they travel with the reason they failed, and sort the normalized output. All of it runs in the browser — nothing in your secrets list is sent to a server.

The one-step move I keep coming back to

Here is the concrete reason I open this tool a couple of times a week. I maintain a config module that exposes a typed getEnv(name) accessor, and the name parameter is a TypeScript union of every variable the app reads. When someone adds three new variables to the deploy, I don't want to hand-stitch 'NEW_VAR_A' | 'NEW_VAR_B' | 'NEW_VAR_C' into the union and pray I matched the casing. I paste the full updated list, flip the output to TypeScript union, and the converter hands me the literal union in one step — correct quoting, correct pipes, no trailing separator. I drop it straight into the type and the compiler immediately tells me which call sites reference a variable I just removed.

The same list, flipped to JSON array, becomes the source row for our environment docs table. One paste, two outputs, zero retyping. That round-trip used to be a five-minute careful-copy chore; now it is two clicks.

Worked example: a plain list becomes a union and a JSON array

Say you paste this into the input — the kind of block you'd lift straight out of a .env.example:

DATABASE_URL
API_KEY
REDIS_URL
STRIPE_SECRET_KEY
LOG_LEVEL

Choose the TypeScript union output and you get a single type-ready expression:

type EnvVar =
  | 'DATABASE_URL'
  | 'API_KEY'
  | 'REDIS_URL'
  | 'STRIPE_SECRET_KEY'
  | 'LOG_LEVEL';

Now flip the same input to JSON array without touching the list:

[
  "DATABASE_URL",
  "API_KEY",
  "REDIS_URL",
  "STRIPE_SECRET_KEY",
  "LOG_LEVEL"
]

Five names in, two finished artifacts out, both spelled exactly the way you pasted them. If two of those lines had been duplicates from merging branches, enabling unique-rows would have collapsed them before either output was rendered, so neither your type nor your docs would carry the repeat.

Where invalid rows save you

A list of variable names is forgiving, but real input is rarely just names. People paste .env blocks with values attached, support tickets with stray prose, or a docker-compose environment section that mixes keys and comments. The converter treats an entry it cannot accept as a variable — a bare token where a key was expected, a key with illegal punctuation, a value that spans lines without quoting — as an invalid row, and you can choose to keep those rows with the reason attached.

That matters because a silently dropped row is worse than a visible bad one. If a malformed line vanished, your generated TypeScript union would compile fine and simply be missing a variable, and you'd discover it only when production threw undefined. Keeping invalid rows means the broken entry shows up in the output next to why it broke, so you fix the source instead of shipping a quietly incomplete config schema.

Fitting it into a real workflow

A few patterns I'd suggest:

• Scaffolding a .env.example — paste the full set, switch to one-per-line, sort, and you have a tidy template with no values leaking in.
• Documentation tables — render to CSV or Markdown and drop it straight into the wiki. If you need a richer table layout afterward, the CSV pairs naturally with CSV to Markdown Table.
• Typed config — render the TypeScript union and paste it into your config module's accessor type.
• One-off audits — render the SQL IN clause to check which of these keys appears in a config-tracking table.

If your raw paste is messier than a clean name list — full key/value .env content, logs, or copied HTML where you only want the keys — start by pulling the names out with the Environment Variable Extractor, then bring the cleaned list back here to convert it. The two tools are built to hand off to each other.

Why local-only matters here

Environment variable names are not as sensitive as their values, but they still describe your stack: which payment processor you use, which datastore, which feature flags exist. The converter does every step — parse, validate, normalize, dedupe, sort, copy, download — in the browser tab. Uploaded text files are read locally with the File API and never reach a server. You still owe your own judgment when copying output that mixes in customer data or access tokens, but the tool itself never becomes the leak.

The size sweet spot is a few megabytes: a .env file, a pasted secrets list, a docker-compose environment block. If you somehow have a config dump larger than that, chunk it locally first, then convert each piece.

Parse once, render anywhere. That is the entire pitch, and after a year of hand-quoting unions I can tell you it removes a small, recurring, surprisingly error-prone task from the week.

---

Made by Toolora · Updated 2026-06-13