Free SBOM Validator for CycloneDX and SPDX
Checks the document against the official schema, the quality of component identities, dependency references, and how many components are actually usable for vulnerability matching.
Free tool: results are indicative and are not a certification. Use is subject to the Terms of service and the Privacy policy.
Validate a file
Download exampleDrop a CycloneDX or SPDX JSON file
20 MB maximum · up to 20,000 components · processed in this browser
Limits you should know
- Up to 20 MB per file
- Up to 20,000 components
- JSON only — XML and tag-value SBOMs are not parsed
- One file per run
What this result does not prove
Format, quality and identity readiness. It does not query vulnerabilities, verify signatures, or prove CRA compliance.
What is the SBOM Validator?
An SBOM validator checks whether a software bill of materials is structurally valid and whether its components can actually be used. The first question is format: does the document match the CycloneDX or SPDX schema for the version it declares? The second question is usefulness: for each component, is there an identifier and an exact version that an advisory feed can match?
Most SBOM problems are not syntax errors. They are components with no package URL, versions such as “unknown”, vendor blobs with no upstream identity, and dependency references that point at nothing. This validator reports those separately from schema failures, so a document that passes the schema is not automatically treated as ready for vulnerability matching.
Supported formats and limits
| Accepted input | CycloneDX JSON 1.4, 1.5, 1.6 · SPDX 2.3 JSON |
|---|---|
| Enforced limits | Up to 20 MB per file · Up to 20,000 components · JSON only — XML and tag-value SBOMs are not parsed · One file per run |
| Processing | Parsed and analysed in this browser tab. The file is never uploaded, stored or hashed for tracking. |
| Not included | Format, quality and identity readiness. It does not query vulnerabilities, verify signatures, or prove CRA compliance. |
How it works
- Read the file locally. The browser reads the selected JSON file with the File API. Nothing is sent over the network — there is no upload endpoint on this site.
- Detect the format and spec version. The document is identified as CycloneDX or SPDX and checked against the bundled official JSON schema for the declared version.
- Normalise the component tree. Top-level and nested components are collected, duplicate declarations are reconciled and conflicting identities are reported rather than silently merged.
- Check dependencies and identities. Dependency references are resolved against declared identifiers. Each component is classified by identifier (purl, CPE or none) and by whether it has an exact version.
- Report issues with a path and a fix. Every finding carries a rule, a JSON path and, where one exists, a suggested fix. The JSON or Markdown report can be downloaded for a review.
What it checks
- Format detection and declared specification version
- Schema validation against the official CycloneDX or SPDX schema
- Top-level versus nested component counts
- Duplicate and conflicting component declarations
- Dependency and relationship references that point at missing identifiers
- Self-references, duplicate edges and cycles
- Per-component query readiness: missing identity, invalid identity, unsupported ecosystem, missing exact version, ambiguous identity
Common errors and fixes
The file is valid JSON but the schema check fails.
Check the declared spec version first. A CycloneDX 1.6 document validated against the 1.4 schema fails on fields that are legal in 1.6. Fix the structural error at the reported JSON path before reading the quality findings.
XML or tag-value SBOM is rejected.
This tool parses JSON only. CycloneDX XML and SPDX tag-value files must be converted to CycloneDX JSON or SPDX JSON before they can be checked here.
The report says a component is not query-ready.
Add a valid purl or CPE and an exact version. If the component is a vendor blob with no upstream package, declare it as a vendor component and record the limitation instead of inventing an identifier.
Dependency references are reported as broken.
A dependsOn or relationship entry points at a bom-ref or SPDXID that the document never declares. Add the missing component or correct the reference.
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.
Format: CycloneDX 1.5 · schema passed
Components: declared tree, with top-level and nested counts
Query readiness: query-ready of applicable, with the reason per component
Dependency references: broken, duplicate and cycle counts
Issues: severity · rule · JSON path · suggested fixPrivacy and data handling
The SBOM is read and analysed in this browser tab. There is no server endpoint that accepts an SBOM, no storage bucket and no queue. Closing the tab discards the file and the report; downloads are generated locally.
Frequently asked questions
Is this a free SBOM validator?
Yes. It runs without an account, without a card and without an upload. Limits are enforced in the browser and stated before you choose a file.
Which SBOM formats are supported?
CycloneDX JSON 1.4, 1.5 and 1.6, and SPDX 2.3 JSON. XML, tag-value and older SPDX versions are not parsed by this build.
Does a valid SBOM mean the product is secure?
No. Schema validity means the document follows the specification. It says nothing about whether the components contain vulnerabilities, whether the software is configured safely, or whether the product meets the CRA.
Does the validator query vulnerabilities?
No. It reports whether each component can be matched by an advisory feed. It does not call a vulnerability database and does not return CVE matches.
What happens to my SBOM file?
It stays in the browser tab. The site is static and has no upload endpoint. The downloaded report is created locally from the same result you see on screen.
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.