Env to JSON

When you would use this

A .env file looks like the simplest format there is and has no standard at all, which means every loader made its own decisions and they mostly agree. The three that matter are all about quoting. An export prefix is ignored, because files are routinely written so a shell can source them as well. Double quotes process escapes and single quotes do not, an asymmetry inherited from shell syntax that surprises people every time. And a hash starts a comment in an unquoted value but not in a quoted one, which is the difference between keeping and losing the fragment on every URL in the file. A repeated key is reported rather than quietly resolved. The last one wins, which matches the loaders, but a config file with the same setting twice is nearly always a mistake and worth being told about. Nothing is uploaded, and that matters unusually much here. A .env file is by definition the file with the credentials in it, and pasting one into a website is the single worst habit in this whole category of tool.

Questions

Why do single and double quotes behave differently?

The convention is inherited from shell syntax. Inside double quotes a backslash n becomes a newline, and inside single quotes it stays two characters. It catches people out constantly, so the tool follows the same rule the loaders do rather than picking one.

What happens to a hash in a value?

In an unquoted value it starts a comment and everything after it is dropped, which is what every loader does. In a quoted value it is kept. That distinction matters more than it sounds: without it, every URL with a fragment in it gets truncated.

Is my file uploaded?

No. It runs in the page. That matters here because the thing being pasted is usually real: a production URL with a session token in it, a config file with credentials, or an export with customer records.