Exchange CycloneDX as JSON unless you have a reason not to. The specification defines three serializations, JSON, XML and protobuf, with the media types vnd.cyclonedx+json, vnd.cyclonedx+xml and x.vnd.cyclonedx+protobuf. They describe the same object model, so pick by what your consumers read, not by features.
What the specification says
The CycloneDX specification overview lists the current version as 1.7, released on 2025-10-21. It names three documentation sets, JSON, XML and Protobuf, and three media types. It also notes that CycloneDX is published as ECMA-424 by Ecma International, developed by the OWASP Foundation, with Technical Committee 54.
One model, three encodings. A component, a dependency graph, a vulnerability entry or a composition means the same thing in each.
Comparison
| Aspect | JSON | XML | Protobuf |
|---|---|---|---|
| Media type | vnd.cyclonedx+json | vnd.cyclonedx+xml | x.vnd.cyclonedx+protobuf |
| Human readable | Yes | Yes | No, binary |
| Common use | Default for APIs and files | Systems that already use XML schemas | Compact transfer between services |
| Diff in code review | Easy | Easy but verbose | Needs a decoder |
| Tooling support | Widest in practice | Mature | Narrower, check your tools |
The last row is a judgment from the general state of tooling, so test your own consumers before you commit.
When each is the right choice
JSON is the right default. Developers can read it, jq can slice it, and most pipelines accept it. It diffs cleanly in version control.
XML makes sense when the receiving system is built around XML validation and tooling, as some enterprise and government pipelines are. If a customer asks for it, produce it from the same model, not by hand.
Protobuf fits when size and parsing speed matter, for example a service that passes many large documents internally. Check that every gateway and tool in the path recognizes its media type before you rely on it.
Practical rules for exchange
- Set the correct media type in the content type header or in your file naming convention.
- Include the spec version in the document, and validate against that version's schema.
- Generate once and convert, instead of maintaining two generators. A conversion step can drop data if the target format lacks a field, so test round trips.
- State in your intake rules which versions and formats you accept.
- Sign or hash the file you actually send, because a converted copy has a different digest.
- Keep one copy as the source of truth, and label derived copies.
For file names, see SBOM file names and media types.
What the object model contains
The overview lists the main sections of the model: BOM metadata, components, services, dependencies, compositions, vulnerabilities, formulation, annotations and definitions. Whichever encoding you choose, the content comes from those sections. An exchange rule that says only "send CycloneDX" leaves room for a file with only a flat component list. Say which sections you need.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the components and their relationships, the content that every serialization has to carry.
Where this fits
Format choice is a smaller decision than content quality. See CycloneDX or SPDX. Safeguard offers SBOM and dependency scanning, and the free scan is a way to see what an inventory contains.
Quick check
Do the three serializations hold different data?
No. They encode the same object model. Differences are in readability, size and tooling.
Which one should I publish by default?
JSON, because it is readable and widely accepted. Offer others on request.
Sources
Last reviewed: 19 October 2026.
