1. Paste both SBOM documents
CycloneDX and SPDX JSON are both understood, and you can mix formats (one of each) — only each package's name and version are compared.
Paste a before and after SBOM above and click Diff.
Findings
| Change | Package | Before | After |
|---|
Prefer a CLI, or want this in your own CI?
Same logic, zero dependencies, one file:
python3 sbom_diff.py old.json new.json # human-readable
python3 sbom_diff.py old.json new.json --format json # machine-readable
python3 sbom_diff.py old.json new.json --fail-on-change # exit 2 if anything differs
Get sbom_diff.py from the repo — stdlib only, nothing to install, no network calls. Wire --fail-on-change into your own CI to catch an unexpected dependency drift before it merges.
Common questions
Why not just run diff on the two SBOM files?
Both CycloneDX and SPDX documents carry a serial number, a generation timestamp, and tool metadata that differ on every single run even when the package list is byte-for-byte identical. A line-based diff shows all of that noise before it shows you the one package that actually changed. This tool reads only the package name and version from each document and ignores everything else, so the output is the change itself, not the noise around it.
Does this tell me if a new or updated package is vulnerable?
No. This is a structural comparison only — it reports that a package is new, gone, or at a different version, and nothing about whether any version is safe, vulnerable, or appropriately licensed. It makes no network calls of any kind, so it never queries a vulnerability database on your behalf.
Does it upload my SBOM anywhere?
No. Both files you paste are read in this browser and never leave your device. An SBOM can reveal your entire internal dependency tree, including proprietary or unreleased component names, so this page makes no network requests of its own — pasting is the only way it sees anything.
What if the two files are in different formats — one CycloneDX, one SPDX?
That still works. Only each package's name and version are compared, and both formats expose those two fields, so a CycloneDX document can be diffed against an SPDX document from an earlier build with no conversion step.
What about a package that appears twice with different versions in the same build?
Handled directly: packages are matched by name, and the set of versions recorded under that name is compared rather than assuming exactly one. A monorepo pulling in two versions of the same library through different paths is reported as a version gained or lost, not silently collapsed to one or crashed on.
More: how this compares to diffing the raw SBOM JSON files by hand, and how this compares to the official cyclonedx-cli's diff command. If one small version bump produced a report full of changes, see why bumping one package can show up as dozens of changes.