If you opt for making your declarative language a subset of JSON or YAML, presumably it will be a proper subset, with some further expectations and constraints. It makes total sense to use a custom file extension — say, `.mdl`, &quot;my declarative language&quot;, for the sake of discussion. Users will be able to easily find their files written in your language without having to wade through all possible files of the superset format. A `.mdl` file really is its own thing, it&#x27;s not just a .json or .yml file. It may be the case that a `.mdl` file is a just `.json` or `.yml` file, but the converse will not be true.<p>The only advantage I can think of that accrues from using the more common extension is editor support: a user&#x27;s favorite editor may well provide syntax highlighting and checking, auto-indenting, etc. for `.json` or `.yml` files, but not for `.mdl` files out of the box. You might want to develop `.mdl` profiles (sic) for popular editors.<p>Any decent parser for the &#x27;true&#x27; format will accept either a string or a full filename (including extension) and shouldn&#x27;t expect a fixed file extension.<p>Regrettably I can&#x27;t think of a single example right now, but I know I&#x27;ve encountered many programs that use custom file extensions which have turned out to be just some familiar format after all.<p>That said, it&#x27;s another question whether either JSON or YAML is a great choice. I agree with your reservations about both. In fact I&#x27;ve had the very same problem in a couple of development projects, one recently. JSON is friendlier than XML, true, but it&#x27;s not really a language to think in, even declaratively — too much clutter. YAML is certainly versatile enough, but it provides probably more than you need, and it is... yes, obtuse. Of course, it depends on your intended users; I found it was too &quot;programmerly&quot; for mine. I ended up developing a custom parser for a language with more syntactic sugar than YAML, which has its advantages and disadvantages.