INI and .env to JSON Converter
INI files and .env files never had a specification, only conventions that each parser interprets slightly differently. That is manageable when one program reads the file and awkward when you are migrating config into a system that expects JSON. This converter handles both directions and states its assumptions.
How to use it
- Choose INI to JSON or JSON to INI.
- Drop in a .ini, .env, .cfg, .conf, or .json file.
- Download the converted configuration.
How sections become structure
A bracketed section header starts a new object. Keys that appear before any section header go to the top level. So a file with a [database] header followed by host and port produces a database object containing host and port, while anything above that header stays as a root-level key.
A .env file typically has no sections at all, so it converts to a flat object, which is exactly what most configuration loaders want. Leading export statements are recognised and stripped, since shell-sourceable .env files commonly include them.
Everything is a string, and that matters
INI has no type system. port=5432 gives you the text 5432, not the number. debug=false gives you the text false, which is truthy in most languages if you test it directly. This is the single most common source of configuration bugs when moving from INI to a typed format.
The converter deliberately does not guess. Values are emitted as JSON strings, because guessing produces a worse outcome than being predictable: a converter that helpfully turns 08 into 8 or on into true will eventually corrupt a value that mattered. Cast explicitly in your application, where you know what each key is supposed to be.
Quoting, comments, and duplicate keys
Both # and ; are treated as comment markers when they begin a line, since the two conventions are equally common in the wild. An inline # inside a value is kept, because URLs with fragments and passwords with hash characters are more common than trailing inline comments.
Surrounding single or double quotes are stripped from values, which matches how shells and dotenv libraries behave. A value written as PASSWORD="p@ss word" yields p@ss word without the quotes.
Duplicate keys within the same section are resolved last-wins, which is the behaviour of most parsers. If your file relies on duplicate keys accumulating into a list, that intent will not survive, and it was never portable to begin with.
At a glance
| Accepted input | .ini, .env, .cfg, .conf, .json |
|---|---|
| Comment markers | Leading # and ; |
| Type inference | None, all values remain strings |
| Duplicate keys | Last value wins |
Frequently asked questions
Why is my port number a string instead of a number?
Because INI cannot express the difference, and inferring it causes worse bugs than leaving it alone. Cast the value where you read it, at the point where you know the key is meant to be numeric.
Does it handle .env files with export prefixes?
Yes. A line reading export API_KEY=abc123 is treated the same as API_KEY=abc123, because .env files are frequently written to be sourced by a shell as well as read by a library.
What about multi-line values?
Multi-line values are not portable across INI parsers and are not supported here. If you need to store a private key or certificate in configuration, Base64-encode it onto a single line, which is what most deployment systems do anyway.
Can I convert JSON with nested objects back to INI?
One level of nesting maps cleanly to sections. Deeper nesting has no INI representation, so those branches are flattened using dotted key names rather than being discarded.
Read more
CSV, JSON, YAML, XML: choosing a data format — Every conversion between these formats loses something. Knowing what, in advance, prevents most of the resulting bugs.