Protocols & Binary Serialization
Check one key against a partition count. The selected algorithm is Java-compatible Murmur2.
Text is preserved exactly, including spaces and line breaks. An empty byte key is valid; select Null key for an absent key.
68 65 6c 6c 6f
Calculation stays in this browser tab. No key is sent or saved, and no Kafka cluster is contacted.
Applies to Java-compatible keyed Murmur2 routing. Explicit partitions, ignored keys, custom serializers or another partitioner can change the actual destination.
Calculation complete.
A producer sends a customer record to an unexpected partition, even though the visible key looks right. This Kafka partition calculator helps separate a byte mismatch from a routing mismatch: inspect the serialized key, then compare the hash and current partition count.
Kafka key to partition mapping depends on the bytes supplied by the serializer. A numeric key serialized as four binary bytes differs from the same number typed as text. Use hexadecimal or Base64 when reproducing a non-string serializer.
The Kafka partition calculator accepts text and two binary encodings. Equivalent bytes produce the same hash regardless of how you entered them. The hexadecimal preview reveals a trailing newline, a zero byte or a multibyte character that a plain text comparison can miss.
An empty string encoded as UTF-8 is a real zero-length byte array. A null key has no byte array at all. One follows the chosen deterministic hash formula; the other depends on producer state. The result panel shows this distinction instead of inventing a destination.
Choose UTF-8 only if those are the bytes your producer writes. Hex accepts ASCII whitespace and complete byte pairs without a 0x prefix. Standard Base64 requires its normal padding; changing the encoding reinterprets the input instead of converting it.
The default 12 is an example, not a sizing recommendation. Partitions are numbered from zero, so 12 partitions means destinations 0 through 11. Changing the divisor can change a key’s destination while its hash stays identical.
Load abc or foobar from Test vectors and compare the shown signed hash with the fixed reference. Automatic mode waits 350 ms after edits. Turn it off to calculate with Ctrl/Cmd + Enter; export stays disabled while the result is stale.
The engine uses seed 0x9747b28c, little-endian four-byte blocks and 32-bit multiplication. Signed and unsigned hash displays describe the same bits. Routing clears the sign bit with 0x7fffffff before modulo; Math.abs is a different operation and can produce another partition.
UTF-8 preserves spaces, line breaks, case and Unicode form. Hex and standard Base64 let you supply arbitrary serialized key bytes, including 00 and ff. Invalid pairs, malformed padding and noncanonical final Base64 bits fail explicitly instead of silently changing your input.
The test-vector drawer includes abc, foobar and 21 with fixed Apache Kafka expectations. The byte preview initially shows 100 bytes and expands by 100. A JSON report includes all bytes, the algorithm, encoding, key type, partition count and intermediate numeric values.
For a non-null serialized key and the chosen keyed routing policy, compute Murmur2, clear the sign bit, then take the remainder modulo the total partition count. For example, abc has signed hash 479470107 and maps to partition 3 with 12 partitions. Use producer metadata to confirm the actual count.
Yes. Many possible keys map into a finite number of partitions, so sharing a destination is expected. This does not necessarily mean the full 32-bit hashes collide: different positive hashes can have the same remainder. A shared partition says nothing about key equality.
Compare the serialized bytes, total partition count and producer partitioner configuration. Different language clients can use different algorithms; the same displayed string may also serialize differently. An explicit partition or ignored-key setting can override key hashing. Consumer rebalancing changes ownership, not this hash formula.
No. Kafka producers can send records without a key. Whether that is appropriate depends on the application’s grouping and ordering requirements. This page lets you select an absent key explicitly and then reports that the destination cannot be determined by the keyed Murmur2 formula alone.
It depends on the client, version and configuration, as well as runtime state such as batching. Modern Java producers can use sticky behavior; other clients have their own policies. This calculator intentionally returns no fixed destination for null instead of replaying an old round-robin assumption.
The Kafka Murmur2 variant uses the fixed seed 0x9747b28c. With identical serialized bytes, the hash is repeatable across runs. That does not freeze the final destination: changing the partition count changes the modulo operation, and a different partitioner may use another algorithm.
Found a calculation or validation issue?
Use the Kafka partition calculator with bytes captured from your serializer, then compare the intermediate values with your producer’s keyed routing implementation.