Use JSON for almost everything. It is machine friendly, has a published schema, and most tools read it. Choose tag value when people will read or hand edit the file, and keep YAML or RDF for toolchains that already depend on them. SPDX 2.3 requires that all supported formats stay interoperable.
What the specification allows
SPDX 2.3 lists these serializations, with suggested file extensions.
| Format | Suggested extension | Notes |
|---|---|---|
| Tag value | spdx | Flat text, easy to read and diff |
| JSON | spdx.json | Based on ECMA-404, with a JSON Schema in the SPDX spec repository |
| YAML | spdx.yaml or spdx.yml | YAML 1.2 |
| RDF | spdx.rdf | RDF/XML following the W3C grammar |
| Spreadsheet | none suggested | Supported, for humans and review |
XML is not supported in this version. The specification says it is in development for the next release. The conformance text also says that interoperability between all supported formats shall be preserved, so choosing one should not lock you out.
A decision guide
- Will a pipeline consume it? Use JSON. Validate it against the schema in CI.
- Will a person review or hand write it? Use tag value. It reads top to bottom, and each line is a field.
- Does your tool already speak RDF or YAML? Stay there, but convert to JSON when you share outside the team.
- Is a reviewer working in a spreadsheet? Export a copy for them. Keep JSON as the record.
Practical points
- Name files with the suggested extensions so tools and people recognize them. A file called sbom.json tells nobody which standard it follows.
- Keep one canonical format and generate others from it. Converting back and forth can lose details, so avoid round trips.
- If a customer asks for a specific format, ask which version too. SPDX 2.3 and the newer 3.0 differ in structure.
- Docker's build attestation uses JSON encoded SPDX documents, and GitHub's repository export is SPDX. In practice, JSON is what you will meet.
Validation is the step teams skip. Whatever format you choose, run a validator in CI and fail the build on errors. A file that parses is not necessarily a file that conforms, and a consumer's tool may be stricter than yours. Test the file with the tool your customer uses if you know which one it is, since a rejected file costs more time than a slightly slower build.
Quick check
Is SPDX available as XML?
Not in 2.3. The specification lists it as in development for a later release.
Does the format change what the SBOM says?
It should not. The specification requires interoperability across supported formats, though converters can still drop fields.
Safeguard's SBOM and dependency scanning reads both SPDX and CycloneDX, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
