DEV Community

Rayan Ahmad
Rayan Ahmad

Posted on

Why I stopped using online utilities for my env variables

A few weeks ago I needed to quickly convert a .env file to JSON for a script. Did what I always do, opened the first free converter tool that came up, pasted the file in, got my output, moved on. It wasn't until later that night that it actually registered: that file had a real database password in it. I'd just pasted production-adjacent credentials into a random website with no idea what happens to that input after I hit submit.
That's the thing about most free online dev tools. The formatters, converters, calculators we all reach for to save five minutes are usually thin frontends sitting in front of a backend that does the actual processing. Sometimes that's disclosed somewhere in a privacy policy. Often it isn't, or the policy is vague enough that it doesn't really tell you anything. Either way, whatever you paste in gets sent off your machine before you get a result back, and the only thing standing between that data and a server log somewhere is whatever the site operator decided to do with it.
For a lot of use cases that's a non-issue. Converting a snippet of CSS to SCSS doesn't expose much if it ends up in a log somewhere. But infra and devops tooling is a different category of input entirely. A crontab can reveal internal job names and what your systems actually do on a schedule. An env file often has real connection strings, API keys, or credentials in it. A log dump can have customer PII scattered through it. None of that is data I want leaving my machine just to save myself a few minutes of manual parsing.
So I started looking at what it would actually take to do these conversions entirely client-side, no backend involved at all. It changes more than you'd expect. There's no submit button, because there's no request to submit, results just have to update live as you type. There's no async loading state to lean on. Every parser has to run synchronously (or in a local worker) directly against whatever's in the input field, fast enough that it doesn't feel laggy on every keystroke, and robust enough to not choke on partial or malformed input while someone's still typing.
If you want to check whether a tool's "client-side" claim actually holds up, it's easy to verify yourself. Open dev tools, go to the Network tab, then paste something into the tool and watch for outbound requests. If the tool also lets you select a file instead of pasting, try that path too, a genuine local file read via the browser's File API won't trigger any network activity either. Or just disconnect from the internet entirely and see if the tool still works. If a "file upload" button doesn't actually make a request anywhere, it was never really an upload, it's just a local file read, and that's a meaningfully different thing from what most "upload" UI implies.
I ended up building a small set of tools around this exact problem, things like crontab-to-systemd conversion, env-to-JSON and back, a CIDR subnet calculator, and a PII log scrubber, all running fully in-browser at configdev.com. Built them mostly because I kept needing them myself and didn't want to keep pasting real config into tools I had no visibility into.
This isn't really meant to be a pitch for that specific project though. It's more of a habit I'd recommend picking up regardless of what tool you end up using: before pasting anything sensitive into a website, check the network tab first. Takes ten seconds and tells you exactly where your data is actually going.

Top comments (0)