VoriTools

SBOM Viewer

Paste a software bill of materials to review its component inventory. The report summarizes declared data; it does not scan for vulnerabilities.

Runs locally in your browser
View category: DevOps & Diagnostics (18)
This tool processes all data locally in your browser.
CycloneDX or SPDX JSONPaste an SBOM document to list its components, versions, licenses and missing license data locally.
Components

How to read a CycloneDX or SPDX bill of materials in this viewer

The viewer reads a CycloneDX or SPDX document in JSON form and lists every component it declares: name, version, type and license. The report counts the license values found in the document and the components that carry no license at all.

All of it runs in the page. The document is never uploaded, the viewer keeps working with the network disconnected, and a vendor bill of materials can be checked without sending it anywhere.

  1. Paste the CycloneDX or SPDX JSON into the input box, or press Load example for a two-component CycloneDX document.
  2. Press Analyze locally. The report shows the detected format, the component count, the license summary and the number of components without a license.
  3. Read the component table: name, version, license and type, one row per entry in the components or packages array.
  4. Press Copy when the report has to go into a ticket or a review, and Clear to empty the input and the results.
  5. Compare anything you intend to publish with the source document: the viewer reports what the file declares, nothing more.

What the report lists, and what it does not check

What the viewer reads from a CycloneDX document

CycloneDX components are read from the components array. Each entry contributes name, version, type and the licenses it declares; a license is printed as its SPDX id (MIT), its name (Custom License) or the expression the document uses (MIT OR Apache-2.0). The specVersion field labels the report, so a CycloneDX 1.6 file is shown as CycloneDX 1.6.

A component without a version shows a dash, and a component without a name shows (unnamed). Neither stops the analysis, and both are worth fixing in the document itself before the bill of materials is published.

What the viewer reads from an SPDX document

SPDX packages are read from the packages array. The license column prefers licenseConcluded and falls back to licenseDeclared when no conclusion was recorded, because SPDX writes NOASSERTION or NONE when a license was never determined. Those two values count as a missing license, not as a license named NOASSERTION.

versionInfo feeds the version column and primaryPackagePurpose (APPLICATION, LIBRARY and so on) feeds the type column; the spdxVersion field labels the report. The viewer prints these declared values as they are, without resolving a license expression into its obligations.

Table size and the limits of the report

The component table shows the first 500 rows; the counters, the license summary and the report JSON always cover the whole document, and a note appears in the findings whenever the table is cut short. Very large documents are limited by the memory of the browser tab rather than by an upload quota.

This is a reader, not an auditor: it does not list the dependencies array, verify hashes or signatures, validate the file against the CycloneDX or SPDX schema, resolve license obligations, or match components against a vulnerability database.

Recent tools: