Paste a CloudEvents envelope or ce-* headers with a body to inspect missing context fields and payload conflicts. Copy the normalized event JSON or HTTP binary-mode headers.
Runs locally in your browserUse structured JSON or HTTP binary mode. This tool does not publish an event or call an endpoint.
CloudEvents Inspector reads one event at a time in either shape the HTTP protocol binding defines: a JSON envelope (structured content mode) or a block of ce-* headers with an optional body (binary content mode). It checks the context attributes against CloudEvents 1.0, then rewrites the same event as normalized structured JSON and as binary-mode headers.
Everything runs in this tab. The tool does not publish an event, call an endpoint or contact a schema registry, and the network log stays empty while you paste and convert.
Input that starts with an opening brace is parsed as a JSON envelope. Anything else is read as a header block, and a block whose Content-Type is application/cloudevents+json is decoded as structured JSON with the body underneath the headers.
In binary mode the body is everything after the first blank line. When the content type declares JSON the body becomes an object, otherwise it stays a string, so a text payload and a JSON payload are kept apart.
The four required attributes specversion, id, source and type are reported separately when they are absent or empty and when they have the wrong type; specversion has to be 1.0, source has to be a non-empty URI reference without whitespace, and time has to be an RFC 3339 timestamp including its offset. data and data_base64 are mutually exclusive, data_base64 has to be valid base64, and an event without a payload is a warning rather than an error because the specification allows it.
Extension attributes are counted and carried through. A JSON null on a context attribute is treated as unset, which follows the JSON format specification: subject: null disappears from the normalized output, while data: null is preserved as an explicit null payload.
The normalized structured event lists the core attributes first, then the extension attributes in alphabetical order, then the payload. Copy takes the panel verbatim, so the result can be pasted straight into a test fixture or a diff.
The binary-mode headers contain one ce-* header per context attribute, extensions included, and a Content-Type header only when there is a payload to describe. The payload follows after a blank line; data_base64 is copied through unchanged and its reported size is the decoded length, not the length of the base64 text.
This is an envelope check. The payload is never validated against a schema, CloudEvents signatures are not verified, and broker-specific rules are out of scope. Extension attribute names are not checked against the naming rules in the specification either.
A green result therefore means the event is well formed, not that a receiver will accept it. When an integration still fails, compare the event against your broker documentation or the specification conformance tests before changing the producer.