The obvious first move when you want to know what changed between two SBOMs is diff old.json new.json, or pasting both into a generic JSON-diff tool. Both are close to useless for this specific question, and the reason is structural rather than a quality problem with either approach: a SBOM document carries metadata that changes on every generation run, and that metadata buries the one thing you actually asked about.
A raw diff or generic JSON-diff tool is correct and complete for comparing two JSON documents field-for-field. Its limit here is structural: a CycloneDX or SPDX document embeds a serial number, a generation timestamp, and the generating tool's own version string, and every one of those differs between two runs even when the package list is identical. On a real SBOM with hundreds of components, that metadata noise arrives before the one line you actually care about.
This tool reads only each component's name and version from both documents — CycloneDX or SPDX, and the two can even be mixed — and reports exactly which packages were added, removed, or changed version. It ignores every field a raw diff would show you that has nothing to do with what the build actually contains.
| Question | Where to answer it |
|---|---|
| Did any package get added, removed, or bumped between two builds? | This tool's added / removed / version-changed lists. |
| Is a required SBOM field present and correctly formatted on every component? | Neither tool answers this — that is document validation, not change detection. |
| Can I compare a CycloneDX build against an SPDX build from before a tooling switch? | This tool. Only name and version are compared, and both formats expose them. |
| Is an added or updated package actually safe to ship? | Neither tool can answer this — both are structural comparisons with no vulnerability or license data. |
| Is anything I paste uploaded anywhere? | No, for this tool — everything runs in your browser. A generic online JSON-diff tool may log or cache what you paste; check its own policy before pasting a full dependency inventory into one. |
Mostly noise. A CycloneDX or SPDX document embeds a serial number, a generation timestamp, and the generating tool's own version, and every one of those fields differs between two runs even when the package list is byte-for-byte identical. On a real SBOM with hundreds of components, the real change — one package added, one bumped — is a handful of lines lost inside dozens of metadata lines that changed for no reason you care about.
Yes, when you need to audit the SBOM document itself rather than the packages it describes — checking that a required field like a license expression or a supplier name is present and correctly formatted on every component, or verifying the document's own metadata (spec version, tool provenance) for a compliance record. That is a document-validation task, not a change-detection task, and a raw JSON diff or a schema validator is the right tool for it.
You can, but an SBOM is a complete inventory of your build's dependencies, and for a proprietary product that inventory itself can be sensitive — internal package names, an unreleased component, or the sheer shape of your dependency tree. Uploading it to a third-party web tool just to answer "what changed" is a real information disclosure for a question that does not need one. This page reads both files in your browser and never sends them anywhere.
No. Neither a raw diff nor this tool's structural comparison says anything about whether an added or updated package is vulnerable, malicious, or appropriately licensed — both only show you that a change happened. Deciding whether the change is safe to ship is a separate step this tool does not do.