Kafka Partition Calculator
Compose a record and see exactly which partition its key lands on — computed with Kafka's own murmur2 partitioner, no broker required.
In-browser & private
Headers
Partition
—
Where keys land
Key bytes 0
Value bytes 0
Headers 0
Payload 0 B
Why the partition matters
Kafka guarantees order within a partition, never across a topic. So "will these two events be processed in order?" is really "do these two keys hash to the same partition?" — and that is the question this page answers without a cluster.
- The number is real. The partition is computed with a port of
Utils.murmur2from Kafka itself, thentoPositive(hash) % partitions, which is precisely what the default partitioner does. It is verified against the Java original. - A null key means no guarantee. A record with a null key is not hashed at all — the sticky partitioner batches it wherever is convenient, so two null-key events can be processed out of order even if you send them a millisecond apart. An empty string key is a different thing entirely: it serialises to a zero-length array, which is not null, so it is hashed like any other key and always lands on the same partition.
- The bytes are what get hashed, not the string. These numbers assume
StringSerializer, which is UTF-8 by default. Serialise the same key as an Integer, or with Avro or JSON, and the bytes differ, so the partition does too. - Changing the partition count re-shuffles everything. The modulo is over the partition count, so adding partitions sends existing keys somewhere new — and ordering across that change is lost. Try it with the partitions box.
- Skew is visible. The spread chart shows where a set of sample keys land. A tall bar next to empty ones is a hot partition, which is how one consumer ends up doing all the work.
Frequently asked questions
- Is this really the partition Kafka will choose?
- Yes, for a keyed record with the default partitioner. The number comes from a port of
Utils.murmur2followed bytoPositive(hash) % partitions, which is exactly whatBuiltInPartitioner.partitionForKeydoes. It is checked against the Kafka client itself across hundreds of keys and every partition count on this page. - Does an empty key behave like no key?
- No, and this catches people out.
StringSerializerturns an empty string into a zero-length byte array, which is notnull, so Kafka hashes it like any other key and it always lands on the same partition. Only a genuinely null key skips hashing and goes to the sticky partitioner. Use the checkbox to say which you mean. - Will my two events be processed in order?
- Only if they share a partition, because Kafka orders within a partition and never across a topic. Two records with the same key always share one, so the practical question is whether your keys collide. That is what the partition number here answers.
- What happens when I add partitions later?
- Existing keys move. The partition is the hash modulo the partition count, so changing the count re-maps almost everything, and ordering across that change is lost. Records already written stay where they are, so a consumer can see a key's history split across two partitions. Change the partitions box here to see the reshuffle before you do it for real.
- Why does the same key give a different partition in my app?
- Almost always the serializer. The partitioner hashes bytes, not strings, so these
numbers hold for
StringSerializerwith its default UTF-8. An Integer, Avro or JSON serializer produces different bytes and therefore a different partition. A customPartitioneron the producer overrides all of this. - Does this send anything to a cluster?
- No. A browser cannot speak Kafka's protocol at all, since it is raw TCP rather than HTTP. Everything here is computed in the page, and the code it produces is for you to run yourself.