How do Avro, Protobuf and JSON differ as Kafka event formats?

The three formats differ along four axes: schema enforcement, serialized size, human readability, and evolution support. Avro is a binary format that requires a schema for both writing and reading. The schema is typically stored in a schema registry, and the payload contains only the schema ID plus the binary-encoded data. Avro has strong schema evolution support with well-defined compatibility rules, and it is compact because it does not repeat field names in every record. Protobuf is also a binary format with a schema (a .proto file), but it uses field numbers instead of field names, which makes it more resilient to field reordering. It is also compact and has strong evolution support, and it is widely used outside Kafka, which makes it attractive for polyglot environments. JSON is a text format that is human-readable and easy to debug, but it is verbose, has no enforced schema by default, and its evolution support is weak unless you pair it with a schema registry and JSON Schema.

The mechanism matters because it affects performance and evolution. Avro and Protobuf are both compact and fast to serialize and deserialize, but Avro is often slightly more compact for record-heavy data because it does not carry field numbers either; it relies on the schema's field order. Protobuf carries field numbers, which adds a few bytes per field but makes it more robust to schema changes that reorder or remove fields. JSON is the most verbose; a JSON record can be 2-5x larger than the equivalent Avro or Protobuf record, which matters at high throughput because it increases network and storage costs. For evolution, Avro's compatibility rules are well-defined and enforced by the schema registry. Protobuf's evolution rules are also well-defined but rely on field numbers and reserved ranges. JSON Schema is less mature and less widely enforced. A common mistake is to choose JSON because it is easy to read, then discover later that the size and lack of schema enforcement cause problems at scale.

The trade-off is between developer experience and operational efficiency. JSON is the easiest to get started with, the easiest to debug, and the most interoperable with non-JVM systems. Avro is the most Kafka-native and has the best schema registry integration, but it is less familiar to developers outside the Kafka ecosystem and its binary format is harder to inspect without tooling. Protobuf is a good middle ground: it is binary and compact like Avro, but it is widely used in microservices and gRPC, so many teams already have Protobuf tooling. The choice often comes down to what the organization already uses. If you are a Kafka-first shop, Avro is a natural fit. If you are a gRPC-heavy shop, Protobuf is a natural fit. If you have many non-JVM consumers or need human-readable events for debugging, JSON with a schema registry is a reasonable choice, but be aware of the size cost. Version note: all three formats are supported by Confluent Schema Registry, and the serializers/deserializers are stable. The main evolution is in tooling and registry support, not in the formats themselves.