For what purpose? Document specifications, data serialization, schema-ful data?<p>JSON's data model lines up much better with common data structures in programming languages, while the often-maligned child-element vs. attribute distinction in XML makes a lot of sense to me to distinguish between globally relevant metadata (attributes) vs. data that can stand on its own (elements).<p>When HTTP APIs started winning out at the expense of SOAP or XML-RPC APIs, JSON became preferred because there was no schema to validate and a client could just parse out the fields they were interested in and ignore the rest.<p>Nowadays, more and more deployments add a JSON Schema, officially discouraging that practice and negating one unique differentiator it had versus XML. They're both text-based formats you have to parse, and for internal, non-outward-facing purposes I'd rather use a binary serialization format instead for compactness and because I control both endpoints.<p>My other preferences are, for outward-facing purposes (like a HTTP API return payload), a custom mediatype based on JSON or XML (in that order, because JSON has more community goodwill); for configuration files, neither because the're both awful to type in a line-oriented setting; and for protocol or file-format type things that could conceivably stand on their own and be called a 'document' (like a self-contained file at rest), XML or binary because they allow strongly typed, well-specified formats with less developer effort -- not JSON.