Kafka Message Size Calculator
The size that actually crosses the wire — record overhead, headers, batching and compression — checked against the broker limits you are about to hit.
In-browser & private
Message value (paste the real payload)
Ctrl + Enter
Breakdown
Paste a payload and press Calculate.
Record —
Batch, raw —
Throughput —
Why this is bigger than key + value
- Every record carries v2-format overhead. Attributes, timestamp and offset deltas, and a length varint for the key, the value and the record itself. On a small message that overhead is a noticeable fraction of the total.
- Headers are not free. Each one costs its key and value bytes plus two varints — a tracing header on every message is real traffic.
- Limits apply to different things.
max.request.sizeis the producer request,message.max.bytesthe broker limit on a batch. Sizing against a single record is how a producer that looked fine starts failing under load. - Compression applies to the records, not the batch header. The 61-byte header is sent uncompressed, which is why a batch of one compresses far worse than a batch of a thousand.
- Records in a batch are not all the same size. Each carries its offset and timestamp as deltas from the batch, and those are varints, so the 64th record onwards needs an extra byte and the cost keeps climbing. Multiplying one record by the batch size under-reports a batch of fifty thousand by about 90 KB. The figures here sum the records instead.
- The compressed number is a guess; the uncompressed one is not. How well a payload compresses depends entirely on the payload, so the report checks the exact uncompressed size against both limits first and shows the compressed estimate separately.
Frequently asked questions
- Why is my record bigger than the key plus the value?
- Because the v2 record format wraps them. Every record carries an attributes byte, its offset and timestamp as deltas from the batch, a length varint for the key, one for the value, a header count, and a varint holding its own total length. On a 200-byte payload that is a noticeable slice of the total, and on a 20-byte one it dominates.
- Which limit does a broker actually enforce?
message.max.bytesis the broker's cap on a record batch, measured after compression, and it defaults to 1,048,588 bytes.max.request.sizeis the producer's own cap, defaulting to 1,048,576. A single record that fits comfortably can still fail once the producer batches a few hundred of them, which is why this page sizes the batch rather than the record.- Can I trust the compressed figure?
- Treat it as a sketch. The ratios in the dropdown are typical rather than measured, and real compression depends completely on your payload: repetitive JSON compresses far better than already-compressed bytes or random identifiers. The report checks the exact uncompressed size against both limits first, so the part that matters does not rest on a guess.
- Do all the records in a batch cost the same?
- No. Each one stores its offset and timestamp as a delta from the batch, encoded as varints, so the 64th record onwards needs a second byte for its offset and the timestamp delta grows as the batch spans more time. This page sums the records rather than multiplying one of them, which is why the batch total here is a few hundred bytes larger than a back-of-envelope figure.
- Does the 61-byte batch header get compressed?
- No, only the records inside it. That is why batching matters so much: one record in a batch carries 61 uncompressed bytes of overhead, while a thousand records share the same 61 bytes between them.
- Is my payload sent anywhere?
- No. The sizing runs in this page, so a production payload can be pasted here safely. Nothing is uploaded and nothing is stored.