CycloneDX Validator

Validate a CycloneDX SBOM in JSON or XML against the official schema for its version, with the precise path of every error and what to do about it.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Drop a CycloneDX SBOM (JSON or XML)

Up to 64 MB. Validated in your browser, in a background worker.

Or paste the document

Which versions, and how they are checked

CycloneDX JSON 1.4, 1.5, 1.6 and 1.7 are validated against the official JSON schemas published by the CycloneDX project, bundled unmodified with this page. The version the document declares in specVersion selects the schema, so a 1.6 document is checked as 1.6, not against whatever is newest. Our test suite runs every valid and invalid example in the CycloneDX specification repository for those four versions (269 documents), and each one is classified correctly.

CycloneDX XML 1.4 to 1.7 is read and checked for structure and references: every component needs a type and a name, identifiers must be unique, and dependencies must point at real elements. It is not validated against the XSD, and the result says so every time. For full XML schema validation, convert the document to JSON with the CycloneDX CLI and validate that.

Versions 1.3 and older, and any document that is not CycloneDX, are reported as unsupported. They are never reported as valid.

What the schema cannot catch

A document can satisfy the schema and still be broken. So, beyond the schema:

Every bom-ref must be unique. Two components with the same identifier make every dependency that names it ambiguous.
Every ref and dependsOn entry in the dependency graph must exist.
Every Package URL is parsed with the purl rules for its ecosystem. An invalid purl is a warning, because tools that match advisories by purl will silently skip that component.

XML is parsed defensively

XML SBOMs come from build systems you may not control, and XML parsers have a history of being turned against the machine that parses them: XXE file disclosure and entity-expansion denial of service. The reader used here refuses any DOCTYPE or ENTITY declaration outright. It accepts only the five predefined entities, caps depth and element count, and has no code path that fetches anything.

Frequently asked questions

Is my SBOM uploaded?

No. It is read and validated in your browser. A proprietary SBOM is a full inventory of what your product is made of; it should not be posted to a third-party validator.

Why is an invalid purl only a warning?

The CycloneDX schema only requires purl to be a string, so the document is still valid CycloneDX. The warning is about usefulness: vulnerability databases key on purl, so a malformed one means that component is never matched.

Can it check SPDX?

Use the SPDX Validator. This page recognises SPDX documents and points you there rather than validating them against the wrong rules.

Why did a document from my build tool warn about a repeated bom-ref?

The specification requires every bom-ref to be unique, but the schema cannot enforce it and some generators repeat formulation objects. A repeat on a component is an error; elsewhere it is a warning.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.