SBOM Diff: compare two firmware SBOMs
Matches components by package identifier, then reports added, removed and updated versions between a baseline and a new release. Unmatched components are reported as unmatched, never silently ignored.
Free tool: results are indicative and are not a certification. Use is subject to the Terms of service and the Privacy policy.
Choose the baseline and the new release
Download exampleA · Baseline
Drop the baseline SBOM
20 MB max · up to 20,000 components
B · New release
Drop the new SBOM
20 MB max · up to 20,000 components
Limits you should know
- Up to 20 MB per file
- Up to 20,000 components per file
- Two files per comparison
- Component identity comparison only — no dependency graph inference
What this result does not prove
Identity and version comparison. It does not tell you whether a change is exploitable, whether a signature is valid, or whether the release is authorised.
What is the SBOM Diff?
An SBOM diff compares two software inventories — usually a baseline firmware release and a new one — and reports what changed. The useful unit is a component identity plus an exact version, not a file hash: a new build changes the hash even when nothing in the inventory changed.
This tool matches components by package URL first, then CPE, then declared name. A version becomes an update only when each side has exactly one unmatched exact version; other multi-version differences are reported as a removal plus an addition instead of inventing an upgrade.
Supported formats and limits
| Accepted input | CycloneDX JSON 1.4–1.6 · SPDX 2.3 JSON |
|---|---|
| Enforced limits | Up to 20 MB per file · Up to 20,000 components per file · Two files per comparison · Component identity comparison only — no dependency graph inference |
| Processing | Both files are read and compared in this browser tab. Nothing is uploaded. |
| Not included | Identity and version comparison. It does not tell you whether a change is exploitable, whether a signature is valid, or whether the release is authorised. |
How it works
- Load two files. Choose a baseline and a new-release SBOM. Both are read locally; the comparison never leaves the browser.
- Resolve identities. Each component is keyed by purl without its version, then CPE, then name. Duplicate declarations are collapsed and counted.
- Compare exact versions. Matching identities are compared by exact version. A version becomes “updated” only when the pairing is unambiguous; otherwise both sides are reported as removed and added.
- Report the change set. Added, removed, updated and unchanged rows are shown separately, with a filter and a CSV or JSON export.
What it checks
- Component identities present in the new release but not the baseline
- Identities removed from the new release
- Unambiguous version changes for a matched identity
- Components unchanged between the two documents
- Duplicate declarations collapsed during matching
- Unsupported or unreadable input, reported as an error rather than an empty diff
Common errors and fixes
The diff shows a component as removed and added instead of updated.
The tool could not pair the versions unambiguously — for example, one side has several versions of the same identity. This is deliberate: it avoids inventing an upgrade that the documents do not support.
Two SBOMs that should match produce large change sets.
Compare the identity strategy in both files. A generation tool that emits only names on one side and purls on the other cannot be matched reliably. Regenerate both inventories with the same identifier policy.
The file is rejected before comparison.
Both files must be CycloneDX JSON 1.4–1.6 or SPDX 2.3 JSON within the stated size and component limits. XML and tag-value files are not parsed.
The comparison is empty for identical files.
That is expected: the result shows zero added, removed and updated components. A clean diff is not evidence that the release is secure — only that the component list did not change.
Example output
The result is a report, not a score. This is the shape of the output you can export; the example reports show the full engine output for a synthetic firmware SBOM.
Summary: added · removed · updated · unchanged
Rows: change type · identity · baseline version · new version
Matching: purl, then CPE, then declared name
Export: CSV for a review, JSON for the full comparison recordPrivacy and data handling
Both SBOMs are read and compared in this browser tab. No file content, component name or hash is transmitted. The exports are generated locally from the in-memory comparison.
Frequently asked questions
Can I compare a CycloneDX file with an SPDX file?
Yes. Each document is parsed and normalised to a component identity before comparison, so the two files do not need to use the same format.
Does the diff tell me whether a version change is a security fix?
No. It reports that a component version changed. Whether the change fixes a vulnerability, introduces one or is exploitable in your product requires advisory data and product context that this tool does not have.
Are dependency graphs compared?
No. The comparison is over declared component identities and exact versions. Dependency relationships are not diffed, so a changed edge between unchanged components will not appear.
How large can the files be?
Up to 20 MB and 20,000 components per file. The limit is checked before the file is read, so an oversized file fails immediately.
Related resources
Where this fits in the product workflow
The free tools answer one question at a time. EmbedHarbor is building the connected workflow around them — product versions, supplier components and release evidence. Product-version storage and monitoring are Early Access, not generally available.