STIX 2.1 Validator

Validate a STIX 2.1 bundle locally against the specification's structural rules, with the exact JSON path of every problem and the object graph drawn out.

Runs locally

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

Drop a STIX 2.1 bundle or object

JSON, up to 32 MB. Read and validated in your browser.

Or paste JSON

What is checked

Everything the STIX 2.1 specification makes mandatory for JSON content. Every object needs a type and an identifier of the form type--UUID whose prefix matches the type. Domain and relationship objects need spec_version: "2.1", created and modified. Timestamps must be UTC with a literal Z, and impossible calendar dates such as 30 February are rejected rather than rolled over. Each object type then has its own required properties: an indicator needs pattern, pattern_type and valid_from, a malware object needs is_family, and a report needs published and object_refs.

Patterns are parsed, not pattern-matched

An indicator whose pattern "looks right" but does not parse is the defect most likely to break an import into a threat-intelligence platform. The validator runs a full parser for the STIX Patterning grammar. It covers comparison and observation expressions, AND, OR and FOLLOWEDBY, IN lists, LIKE, MATCHES, ISSUBSET, and the WITHIN, REPEATS and START/STOP qualifiers. It checks typed literals (t'...', h'...', b'...'), and it checks that strings use single quotes and escape only \' and \\. A MATCHES regular expression that does not compile is an error.

References are checked inside the bundle

Every _ref and _refs value must be a well-formed identifier. When validating a bundle, a reference to an object that is not in it is reported as a warning, not an error. Sharing communities routinely send objects that point at things the receiver already has. A relationship that points at another relationship is an error, as is a duplicate object with the same modified timestamp.

Your data is never rewritten

Every finding shows the JSON path it refers to (for example $.objects[3].valid_until) and what to change. The tool does not "fix" the file for you. Silently rewriting intelligence changes its meaning in ways the author did not intend, and the next analyst cannot tell.

Limitations

Only STIX 2.1 is supported. A STIX 2.0 document is identified as such, not validated. Custom objects and extension properties are checked for naming and identifier rules only, because their schemas are defined by their authors. The SCO checks cover required properties and value syntax, not every relationship between cyber-observable objects.

Frequently asked questions

Why is a missing referenced object only a warning?

A bundle is a transport envelope, not a closed database. A sighting of an indicator you received last month is valid without the indicator being resent. The warning tells you which references you would need to resolve yourself.

Does it accept STIX 2.0?

No. It recognises 2.0 content (for example spec_version on the bundle) and says so, because a 2.0 document validated against 2.1 rules would fail for reasons that are not defects.

Is my file uploaded?

No. The file is read by your browser and validated in the page. Unpublished intelligence is exactly what should not be posted to someone else's validator.

What does the relationship view show?

Objects as nodes. Edges come from relationship objects and from embedded references such as sighting_of_ref and object_refs. Referenced objects that are missing from the bundle are marked, so you can see which parts of the graph are outside the file.

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.