Why do so many tools have JSON config files?
stagas
22 points
61 comments
September 02, 2026
Related Discussions
Found 5 related stories in 61.1ms across 5,346 title embeddings via pgvector HNSW
- One Go binary, one YAML file, one SQLite database: I wrote my monitoring tool brvier · 26 pts · August 25, 2026 · 49% similar
- That's a Lot of YAML hisamafahri · 68 pts · August 28, 2026 · 44% similar
- Using jq to format JSON on the clipboard stefanvdw1 · 55 pts · September 02, 2026 · 42% similar
- Hyprland 0.55 announced the switch to Lua for its config files matesz · 134 pts · July 20, 2026 · 42% similar
- Files over tools: how we built our agent with a virtual filesystem and bash cjbell · 31 pts · July 09, 2026 · 42% similar
Discussion Highlights (18 comments)
brunoborges
TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments. However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
nottorp
It would be too easy to have every option in a config file documented in comments in the default config file. Think of the poor tutorial industry. It may even make chatbots less useful.
mr_toad
Somewhat off topic, but Oracle database connection strings seem to be a form of Lisp. It makes me wonder why they would choose that.
tosti
JSON is obviously a poor choice. It's job is to interchange data, produced and parsed by computers. ESR had the idea of writing configuration in English. It didn't gain traction at the time, but we have LLMs now. It might be a good idea to revisit the idea of accepting plain english. The LLM output could then be any format that's easy and unambiguous to parse.
gwbas1c
> Why do so many tools have JSON config files‽ 1: Because JSON is a very easy serialization format to work with. I suspect these tools all have configuration classes / objects that are deserialized straight from the config file. 2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.
bonestamp2
For our internal tooling we use something similar to a bash profile config file with name/value pairs separated by linebreaks. So, our configs look something like: env=staging db=0.0.0.0 #descriptive comment etc=true
Super3000
Because JSON is native to the lingua franca of the internet: Java-/Ecmascript. It fits into the poor choices we made, <-- Parse error
Garlef
because JSON is in the following sense "universal": every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON and that's pretty much the barebones you need for a configuration language (of course you can argue about the syntax)
francisofascii
> Why do so many tools have JSON config files‽ Because XML hasn't been cool for about two decades. And suggesting .ini would you laughed out of the room into retirement.
szatkus
> A lot of tech folks resist documentation because they think it provides them with job security. No, we're just lazy.
spottedmarley
JSON just works, everywhere, all the time. Sometimes I'll use SQLite if there is a particular need.
jamesponddotco
I don't know about others, but I use JSON because it's in the standard Go library, and most of the times, I rather use something weird than add a dependency.
mholt
For Caddy we chose JSON because it's fairly universal, maps nearly 1:1 with Go structs (useful for initializing an extensible server), and nearly everything else compiles to JSON one way or another, so you can choose your own config format, really: https://caddyserver.com/docs/config-adapters
climate_denier_
I wish everyone would embrace Amazon's Ion format. Of the data serialization formats it seems the most reasonable with the exception that it can encode S-expressions (so like having data serialization within your data serialization), so it is a bit excessive. https://en.wikipedia.org/wiki/Ion_(serialization_format)
raincole
> Why do so many tools have JSON config files‽ Commenting why options have been set the way they have is just such a basic thing to want to do… Why do tech people have such an aversion to writing things down⁇ That's the whole post. First I don't know why this is posted on HN. Second I don't see how "JSON config" and "writing things down" are the two opposite options.
phforms
I really like the EDN[1][2] (extensible data notation) format that is used mostly by Clojure for config and data transfer/exchange. It is so much more expressive than JSON and supports a well thought-out set of elements for the most common data structures. [1]: https://github.com/edn-format/edn [2]: https://en.wikipedia.org/wiki/Clojure#Extensible_Data_Notati...
zzo38computer
In my opinion, JSON is not the best format and has some problems. Lack of comments is one of the reasons, as they mention in there. Another is the lack of trailing commas (optional trailing commas would be useful for manually written files). However, these are problems with the syntax, and there are also problems with the data, such as a lack of a proper integer type, lack of Infinity and NaN, lack of support for character sets other than Unicode (and ASCII), lack of proper octet string type, etc.
IgorPartola
1. JSON parsers are available at your corner convenience store. 2. The format is too simple to have ambiguous behavior. No weird “yes” means true, 0 means false, odd rules about comments, blah blah blah. It’s hard to fuck up JSON (but obviously not impossible if you get creative). 3. It errors out early in the parsing if you mess it up. 4. Its data types are present in more or less any language. 5. Most configs are just key/value. JSON does this reasonably well. 6. It is easy to generate and validate JSON documents. For some use cases you don’t need a library (though you should use one). 7. There is only one way to do anything (sane). 8. Everyone is familiar with it. 9. It is dynamic. You do not need to pre-define your sections or keys ahead of time. 10. It can easily be auto formatted to look good with zero risk of changing semantics. 11. Data stores often natively support storing and querying JSON objects. 12. If you are old enough to remember the era when every tool invented its own, often very buggy, config format and parser you will also remember the moment you first saw a JSON config file that was parsed with a standard library parser and thought “finally, this is the modern way”, you will understand why JSON continues being popular. It was the first thing that unambiguously worked compared to what came before it. This is like asking why people use their keys to open packages: it might not be the right tool for the job but it’s hard to mess up, is the closest thing to you that can get the job done, and everyone (with functioning hands/fingers) can do it with little issue. I am also certain there is some small but non-zero percentage of people who do it simply because everyone else moralizes about not doing it. Spite is a powerful thing.