Tracing headers
W3C traceparent and content-type recognised, with their byte cost against the message limit
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 content-type: application/json
Decode Kafka record headers, see what each one costs on the wire including the varint lengths, and catch the duplicate keys that different clients resolve differently. Recognises Connect dead letter, tracing and Spring Kafka headers.
Default is 1048576. Used to say what share of the record budget the headers take, since header bytes count toward it just as the value does.
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 headers. 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.
W3C traceparent and content-type recognised, with their byte cost against the message limit
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 content-type: application/json
Header overhead adds up, and it counts against max.message.bytes like any other bytes
app: orders version: 3 region: eu-west-1 retry-count: 0 source: api
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Headers are part of the record and count against max.message.bytes. Many small headers on a small value is mostly headers.
Instead:Include them when sizing.
Headers are not compressed independently and are read by every consumer, including ones that ignore them.
Instead:Keep them small. Put payload in the value.
The record header API is a list, not a map, so the same key can appear more than once and clients differ on which wins.
Instead:Read all of them, or ensure the producer writes each key once.
That single fact is behind most header surprises: the same key may appear many times, and what reads them disagrees about which one wins.
Kafka stores headers as an ordered list and the broker keeps every entry. The Java client gives you Headers.lastHeader(key) for the last one and headers(key) for all of them, while a great deal of application code takes the first entry it finds and plenty of frameworks quietly overwrite into a map. So a record with the same header key twice means different things to different consumers, with no error anywhere. This page keeps duplicates separate rather than merging them, because merging would hide exactly this.
The broker checks the whole record, headers included, against max.message.bytes, and you store and replicate those bytes as many times as your replication factor. Headers also compress poorly compared to a payload, because each one is short and distinct rather than repetitive. The figure on this page includes the varint lengths Kafka writes before each key and value, so it is what the record actually costs rather than the sum of the strings.
With errors.deadletterqueue.context.headers.enable set to true, which is the right setting, Connect attaches the original topic, partition and offset, the failing stage and class, the exception type and message, and the full stack trace. That last one is often several kilobytes on every failed record. Keep it, because without it a dead letter record tells you nothing, and give the dead letter topic a short retention instead: it is a diagnostic buffer, not a store.
A null header value is written as a length of -1 on the wire and an empty one as a length of 0. Kafka preserves the difference and some deserializers do not, so a header used as a flag by its presence alone is more portable than one whose value is null. This page reports them separately for that reason.
Paste key=value or key: value lines, one per line, or a JSON array of objects with key and value. A value written as 0x followed by hex digits is read as raw bytes, and any value that is not valid UTF-8 is shown as hex rather than guessed at. The first = or : on a line separates key from value, because header values very often contain both: a traceparent is full of dashes and colons, and a stack trace contains everything.