A base64 JSON payload
What a consumer actually received, decoded through the encodings Kafka tooling prints
eyJpZCI6MTIzfQ==
A record payload, decoded from base64 or hex. If it starts with a schema registry header, the report says so and names the schema id, because that is the reason it will not parse as anything else.
Base64 is tried before hex, because a record payload usually comes from a console consumer or a log line rather than from a hex dump. Nothing is sent anywhere: the decoding happens in this tab.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
What a consumer actually received, decoded through the encodings Kafka tooling prints
eyJpZCI6MTIzfQ==
A payload that is already readable, and what the tool says about its shape
{"orderId":1001,"status":"shipped"}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Avro and Protobuf payloads contain readable substrings, so a payload can look like broken text while being perfectly valid binary.
Instead:Check the first bytes. A Confluent payload starts with a zero magic byte and a schema id.
kafka-console-consumer applies a deserializer, by default a string one, so anything not valid UTF-8 is replaced with substitution characters before you see it.
Instead:Use a ByteArrayDeserializer with base64 output when the bytes matter.
Most payloads that fail to parse are framed rather than corrupt, and the framing is five bytes people do not know are there.
The Confluent wire format puts a zero magic byte and a four byte big-endian schema id in front of every payload. So a record written through an Avro or protobuf serializer starts with five bytes that are not the message, and reading the whole buffer as JSON fails on the leading nulls while reading it as text shows a few unprintable characters and then nothing useful. Protobuf adds a message-index array after the id, which moves the offset again.
Avro and protobuf binary encodings contain no field names and no type information: the schema turns the bytes into fields, and the record only holds a reference to it. That is what makes them compact, and it is also why losing the registry's _schemas topic makes every existing message permanently undecodable. This page reads the id and stops there, because fetching the schema would mean calling a service.
kafka-console-consumer.sh and most log lines give base64, and a byte dump from a hex editor or xxd gives hex. Base64 is tried first here for that reason, which is the opposite default from the CRC calculator on this site, where the input is usually a byte dump. Same ambiguity, different likely source.
Kafka compresses a whole record batch rather than individual records, and the consumer decompresses the batch before handing over a record. So a payload that looks like compressed bytes is either not a payload, or the producer compressed the value itself before serializing it, which is a decision made in application code rather than by Kafka.
It does not fetch schemas, so an Avro or protobuf payload stops at the header and the schema id. It also cannot tell a bare Avro payload from any other binary encoding, because without a registry header there is nothing to identify it. For the header itself in more detail, the Confluent wire format decoder on this site reads the magic byte and the message-index array; for checksums the CRC32C calculator verifies a whole record batch.