Kafka Avro Schema Validator

A union default belongs to the first branch, and only the first

This is the most common mistake in Avro and it is silent for years. A default value for a union field has to be a value of the union's first branch, so ["null", "string"] takes a default of null and nothing else, and ["string", "null"] takes a string. Avro's Java parser has validated this by default since 1.9, so the same schema is accepted by an older toolchain and rejected by a current one. That is how it reaches production before it fails.

{"name": "note",
 "type": ["null", "string"],
 "default": ""}
// rejected: "" is a string and the
// first branch is null

A field with no default can never be added later

A reader fills a field the writer did not have from that field's default. Without one, the field can only be read from data written by a schema that also had it, so adding it to a registered schema is a backward-incompatible change and the registry rejects the version under the default BACKWARD policy. For a first version this is entirely normal, which is why it is reported here once and as information rather than as a warning per field.

An enum with no default breaks the day you add a symbol

A consumer on the old schema meets a value it has no symbol for and the deserializer throws. Avro 1.9 added an enum default for exactly this, and it only helps if it is already in the schema those consumers are running: adding a default at the same time as the new symbol helps nobody. If the set of values is genuinely open, a string field is the honest answer.

{"type": "enum",
 "name": "Status",
 "symbols": ["NEW", "DONE"],
 "default": "NEW"}

An invalid logical type is ignored, not rejected

That is the specified behaviour rather than a bug. A logicalType Avro does not recognise, or one on the wrong underlying type, is dropped and the field is read as the plain type underneath. timestamp-millis on an int is the usual instance: it is silently ignored, and an int would overflow 24 days into 1970 anyway. Nothing at any stage reports it, which is why it is checked here.

The fingerprint, and what it deliberately ignores

The panel shows Avro's CRC-64-AVRO fingerprint over the parsing canonical form. Two schemas with the same fingerprint are the same schema to a reader, however differently they are written: namespaces are folded into names, primitives are reduced to their bare form, and documentation, aliases, defaults and logical types are stripped. So a schema that only adds documentation has an identical fingerprint, and so does one that only changes a default. It is not the Schema Registry's id, which is a sequence number the registry assigns and cannot be computed from a schema.

What this cannot see

Whether the schema is registered, what version it would be, and whether it is compatible with what is already there. The compatibility checker on this site answers the last one for a chosen level, and it needs both schemas. This page also does not validate data against the schema: the Avro binary decoder and the JSON converter do that.