Open the file and look at the first lines. A CycloneDX document names a bomFormat of CycloneDX and a specVersion. An SPDX document starts with an spdxVersion such as SPDX-2.3. Both can be JSON, but the file extension alone will not tell you which one you have.
What you are looking at
SPDX and CycloneDX are the two formats you will meet most often. Each is a specification for describing software components, how they relate, and who made the description. Neither is "the SBOM." They are containers for the data.
Files arrive with names like sbom.json, bom.xml, app.spdx, or product-1.4.cdx.json. Names help, but people rename files. Always read the inside.
Ten second identification
| Signal | CycloneDX | SPDX |
|---|---|---|
| Top level key | bomFormat, specVersion | spdxVersion, SPDXID |
| Component list | components | packages |
| Relationships | dependencies | relationships |
| Document metadata | metadata | creationInfo |
| Tag-value form | not used | Lines like PackageName: |
SPDX also has a plain tag-value text form where each line is a field name, a colon, and a value. If you see SPDXVersion: SPDX-2.3 at the top of a text file, that is SPDX. If you see angle brackets and a bom root element, that is CycloneDX in XML.
What the version number tells you
Both formats evolve. The SPDX specification's own text says the major version increases when incompatible changes are made and the minor version when changes are backward compatible. So SPDX 2.3 and 2.3.1 should read the same way, while a 3.x file may need a newer parser.
CycloneDX has also added fields over time. For example, the 1.6 reference documents a lifecycles list in the metadata, which tells you at which stage the data was captured. An older file may not carry it. If a field you want is missing, check the spec version before you assume the author left it out on purpose.
Does the format matter?
Less than people think. What you need from an SBOM is a short list: who supplied each component, its name and version, a unique identifier, how components depend on each other, who authored the data, and when. The NTIA minimum elements report lists exactly those and is deliberately format neutral. Both formats can carry all of them.
Where format does matter is tooling. Check that the scanner or inventory system you use can ingest the version you received. If it cannot, do not ask the supplier to redo the work by hand. Ask whether they can export the other format, since many generators produce both from the same data.
Differences you may notice in practice:
- CycloneDX tends to be compact and shaped around components and a dependency graph.
- SPDX has a long history in license compliance, so its license fields are detailed.
- Either can carry package URLs as identifiers.
What to do if the file will not parse
Validate before you blame the sender. Run the file through a JSON linter first. A trailing comma or a truncated download breaks parsing in both formats. Then check the spec version against what your tool supports. Only then write back with a specific error message.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning. If you want a second view of a product you received an SBOM for, there is a free scan at gold.safeguard.sh/scan.
Quick check
Can one SBOM file contain both formats?
No. Each file is one format. A supplier can publish two files generated from the same data, one in each format.
Is XML or JSON better?
Neither is better for content. JSON is easier to search with common tools, so it is the usual choice for people reading by hand.
Sources
- CycloneDX 1.6 JSON reference
- SPDX 2.3.1 document creation information
- The Minimum Elements for an SBOM, NTIA
Last reviewed: 19 October 2026.
