SPDX Validator

Validate an SPDX document in JSON or tag-value form, including the relationship and identifier cross-references that trip up generated files.

Runs locally

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

Drop an SPDX document (JSON or tag-value)

SPDX 2.2 and 2.3, up to 64 MB. Checked in your browser.

Or paste the document

Two formats, one set of rules

SPDX 2.x documents come as JSON or as the line-based tag-value format that many tools still emit. This validator reads both. Tag-value is first converted into the same JSON model the specification defines, then everything is checked against the official SPDX 2.2 or 2.3 JSON schema, whichever the document declares. A tag-value file therefore gets exactly the scrutiny a JSON file does. The SPDX project's own reference examples in both formats validate cleanly here, and its deliberately broken ones fail for the documented reasons.

What is checked beyond the schema

Identifiers: every SPDXID has the SPDXRef- form and is unique, and the document itself is SPDXRef-DOCUMENT.
Namespace: documentNamespace is an absolute URI with no #, because it is the base that element references are resolved against.
Relationships: both ends exist in the document or in a declared external document (DocumentRef-...), and at least one element is DESCRIBED.
Checksums: the hex length matches the algorithm, so a SHA256 of 40 characters is caught.
Licences: every expression is parsed with the SPDX expression grammar. Identifiers are checked against the official SPDX License List, deprecated identifiers such as LGPL-2.0 are flagged with their replacement, and every LicenseRef- used must be defined in the document.
Packages: a package marked filesAnalyzed: false must not carry a verification code.

No licence conclusions are invented

The validator checks that licence information is well formed and uses real identifiers. It never infers what a package's licence "really" is, fills in NOASSERTION, or rewrites an expression. Concluding a licence is a legal judgement that belongs to the document's author.

Unsupported versions

SPDX 3 uses a different, JSON-LD based model. It is recognised and reported as unsupported, not validated against 2.x rules. RDF/XML and YAML serialisations are also reported as unsupported. So is a 2.x document that declares a version other than SPDX-2.2 or SPDX-2.3, such as "SPDX-2.2.1".

Frequently asked questions

Which version of the License List is used?

The one bundled with this page, shown with every result. A document written against a newer list may name identifiers this copy does not know yet. Those appear as errors naming the list version, so you can tell the difference.

Why does a document that declares SPDX-2.2 fail on 2.3 fields?

Because it is validated as what it says it is. Fields such as primaryPackagePurpose were added in 2.3. Declare SPDX-2.3 if you use them.

Is anything uploaded?

No. Parsing and validation run in a background worker in your browser.

References

SPDX 2.3 specification
SPDX License List (data CC0-1.0)
SPDX tools-java (schemas and reference test documents, Apache-2.0)

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.