SBOM Validator
Paste or upload a CycloneDX or SPDX JSON file and check it against the fields CERT-In, NTIA and the format specifications expect — structure, required fields, and common mistakes, instantly.
Your file is parsed and checked in this browser tab only. Nothing is uploaded, transmitted, or stored — see the Privacy section below.
- Paste a file and click Validate, or try one of the example buttons above.
What this tool does
The SBOM Validator checks whether a CycloneDX or SPDX JSON document has the structure and required fields that the format specifications — and CERT-In's accepted formats — expect. It auto-detects which format you've pasted, runs a field-by-field check, and reports pass, warning, or error for each one.
It's built for anyone who needs a quick sanity check before shipping or submitting an SBOM: developers wiring SBOM generation into CI/CD, security engineers reviewing a vendor-supplied file, or compliance teams preparing a submission under CERT-In's SBOM requirements. It complements, rather than replaces, our broader SBOM Fundamentals guide.
What it checks
Auto format detection
Detects CycloneDX vs. SPDX from the document itself — no need to tell it which format you're using.
Field-level results
Every check is reported against a specific field, not just a pass/fail for the whole document.
Three-tier severity
Distinguishes hard errors (spec violations) from warnings (missing recommended fields) so you know what's actually blocking.
Plain-text report
A copyable report is generated alongside the visual results, for pasting into a ticket or PR description.
Four steps
- Paste or upload. Paste JSON directly, or upload a
.jsonfile — it's read locally via your browser's File API. - Auto-detection. The validator looks for a top-level
bomFormatfield (CycloneDX) orspdxVersionfield (SPDX) to determine which rule set to apply. - Structural checks run. Required fields, recommended fields, and common malformations (like a PURL missing its
pkg:prefix) are checked against each component or package entry. - Review results. Pass/warning/error counts and a per-field breakdown are shown immediately — fix and re-validate as many times as you need.
How it's built
The validator is a single-page, client-side-only application. There is no backend for the validation step itself — parsing and rule-checking both run in JavaScript inside your browser tab.
All three stages happen in one browser tab. No network request carries your document anywhere.
This design trade-off is deliberate: it means the validator works offline once loaded, never depends on our uptime, and can't leak a file even by accident. The cost is scope — deep cross-referencing against live vulnerability databases isn't possible client-side, which is why this tool checks structure and required fields, not vulnerability status. For that, see our SBOM tools comparison.
Your file never leaves your browser
No upload
Pasted text and uploaded files are read directly into browser memory. Nothing is sent to a server as part of validation.
No storage
Nothing is written to a database. Refreshing or closing the tab discards everything.
No file-content analytics
We don't log, inspect, or analyze the contents of anything you paste or upload.
What's supported today
| Format | Versions | Status |
|---|---|---|
| CycloneDX (JSON) | 1.2 – 1.6 | Supported |
| SPDX (JSON) | 2.2 – 2.3 | Supported |
| CycloneDX (XML) | — | Not yet supported |
| SPDX (tag-value) | — | Not yet supported |
| SWID tags | — | Not yet supported |
This validator checks core structure and required fields — it isn't a full formal JSON Schema validator against every edge case in the specifications. For exhaustive schema validation, pair it with the official CycloneDX or SPDX tooling referenced in the validation tutorials.
Try it without your own file
Use the Load valid example and Load example with errors buttons in the tool above to see both outcomes. The "errors" example is missing a specVersion, has one component missing its required name and another missing its required type, and includes a malformed PURL that's missing the pkg: prefix — five distinct, realistic mistakes in one file.
Example output
A clean CycloneDX file
- ✓bomFormatbomFormat is "CycloneDX".
- ✓specVersionspecVersion "1.6" is a recognized CycloneDX version.
- ✓componentsFound 2 component(s).
A file with issues
- ✕specVersionMissing required "specVersion" field.
- ✕components[0]Missing required "name" field.
- !metadata.timestampNo metadata.timestamp found.
Frequently asked questions
Is this a full JSON Schema validator?
No — it checks the required and commonly-expected fields that matter most in practice, not every rule in the formal SPDX or CycloneDX JSON Schema. For exhaustive schema validation, see the official tooling linked in Supported Formats above.
Does this check whether my components have known vulnerabilities?
No. This tool validates structure, not security status. Pair it with a scanner — see our vendor-neutral SBOM tools comparison — for vulnerability correlation.
Is my file ever uploaded anywhere?
No. Parsing and validation happen entirely in your browser. See the Privacy section above for the full explanation.
Does passing this validator mean I'm CERT-In compliant?
No. This tool checks SPDX/CycloneDX structural correctness. CERT-In compliance also depends on field-level content (like criticality and end-of-life date) that requires human judgment — see CERT-In SBOM requirements for the full picture.
Can I use this in a CI/CD pipeline?
Not yet directly — today it's a browser-based tool. See API Suggestions below for our planned programmatic access, and our CI/CD integration tutorials for options you can use today.
Planned: a programmatic API
The browser tool covers ad-hoc validation well, but CI/CD pipelines need something scriptable. A REST API is on our roadmap — not live yet — shaped roughly like this:
POST /api/v1/validate
Content-Type: application/json
{ "format": "auto", "document": { "bomFormat": "CycloneDX", "...": "..." } }
→ 200 OK
{
"format": "CycloneDX",
"summary": { "pass": 5, "warn": 1, "error": 0 },
"checks": [ { "level": "pass", "field": "bomFormat", "message": "..." } ]
}Alongside the API, a CLI wrapper and a GitHub Action are the two most-requested integration points. Until these ship, see CI/CD integration tutorials for validating SBOMs today using open-source CLI tools.
Beyond ad-hoc validation
This validator is built for one-off checks. Programs managing SBOMs across many products, releases and teams typically need more: continuous validation in CI/CD, historical tracking, and policy enforcement.
Need an enterprise solution? Compare commercial SBOM platforms including Certhy — alongside Dependency-Track, Black Duck, Mend, Snyk, Sonatype and Anchore — to see which fits your scale and existing toolchain.
We never name a single product as "the best." See our editorial policy for how comparisons on this site are scoped.