Runs entirely in your browser — nothing leaves this page.
SBOM viewer
Inspect CycloneDX and SPDX JSON SBOMs: components, versions and a license summary with filtering.
or paste the JSON below
Reading an SBOM
CycloneDX and SPDX JSON files are normalised into one component table: name, version, licence and package URL, with a licence summary and a filter across every column.
The file is parsed in your browser. That matters for an SBOM, which is a complete inventory of what runs in your product.
Reading one is how you answer questions a build log cannot: which transitive dependency pulled in a GPL library, whether the version you patched actually shipped, and what an auditor will find before they ask.
Does this tell me which components are vulnerable?
No — that is a scanner's job, and it needs a vulnerability database plus a matching engine. This tool answers what is in the artefact: which versions shipped, under which licences, and whether the inventory is what you expected.
CycloneDX or SPDX — which should I generate?
Both are read here, so pick by tooling. CycloneDX tends to fit security workflows and is what most scanners emit; SPDX has the stronger licence-compliance heritage. Consistency across your pipeline matters more than the choice.
Why are XML SBOMs not accepted?
JSON only, deliberately. Both formats define a JSON serialisation, every generator can emit it, and supporting one representation well beats supporting two badly.
Why do so many components show no licence?
That is a finding, not a display bug. Components without declared licence metadata are exactly the ones a compliance review has to resolve by hand, which is why they are grouped under unknown.
Related tools: Dockerfile analyzer, Kubernetes CVEs and K8s manifest validator.