An integer that must be a long
JSON Schema integer has no width, so it maps to long rather than int
{"type":"object","properties":{"id":{"type":"integer"},"name":{"type":"string"}},"required":["id"]}Kafka JSON Schema to Avro
Convert a JSON Schema to an Avro schema, with every keyword that has no Avro equivalent listed rather than dropped quietly. Most of them are the validation you are about to stop enforcing.
A JSON Schema has no namespace and Avro needs one for anything that will outlive the current version, so it is asked for here rather than left out. The title keyword is not used as the record name, because a title is prose and an Avro name is not.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Optional fields
A property not in required becomes a nullable union with a null default
{"type":"object","properties":{"id":{"type":"integer"},"note":{"type":"string"}},"required":["id"]}Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Expecting integer to become int
JSON Schema integer has no width, so the safe mapping is long. Choosing int silently overflows above two billion.
Instead:Constrain with maximum if you want int, and say so.
Assuming a JSON Schema union maps cleanly
oneOf and anyOf are not Avro unions. Avro unions are ordered and resolved by position.
Instead:Simplify the schema first, or hand-write the union.
Skipping the namespace
Avro records without a namespace collide in a registry as soon as two subjects share a record name.
Instead:Set a namespace on every generated schema.
A validation language converted into a wire format
JSON Schema says what a document is allowed to be. Avro says what the bytes are. Most of the difference is things that stop being enforced, and every one of them is listed here rather than dropped quietly.
Every constraint keyword disappears
minimum, maximum, pattern, minLength, maxItems, uniqueItems and the rest have no Avro equivalent, because Avro describes an encoding and not a set of rules. After this conversion nothing in the schema or the serializer enforces any of them. That is not a shortcoming of the converter, it is what the two formats are, and the honest thing is to say which ones you just stopped enforcing.
Optional means something different in each
In JSON Schema a property is optional by being absent from required, and the key can simply not be there. Avro has no absent: every field is written. So an optional property becomes ["null", T] with a default of null, and null has to be the first branch because a union default belongs to the first branch. That shape is the only one that makes an Avro field genuinely optional.
// JSON Schema
"properties": {"note": {"type": "string"}},
"required": []
// Avro
{"name": "note",
"type": ["null", "string"],
"default": null}integer becomes long unless the schema says it fits
JSON Schema's integer has no width. Avro's int is 32 bits and its long is 64, and choosing int for an unbounded integer produces a schema that fails to serialize the first large value. So long is the default here, and a maximum at or below 2147483647 gets you an int.
An enum only converts when its values are legal names
Avro enum symbols follow the name rule: letters, digits and underscores, not starting with a digit. So ["NEW", "DONE"] becomes an enum and ["in-progress", "done"] cannot, and the field is a plain string with the permitted set no longer expressed anywhere. Renaming the values is the fix if the set is closed and worth enforcing.
allOf, tuples and patternProperties have no equivalent at all
allOf is intersection and Avro has nothing that intersects two shapes. A tuple-typed array gives each position its own schema and an Avro array has one item type for every element, so it has to become a record with one field per position. patternProperties cannot be expressed: a map takes every string key or a record names them all, and there is nothing in between. Each of these is reported rather than approximated.
What this handles and what it does not
Draft-07 keywords, and $ref only within the pasted document: a reference to another file or a URL is not followed, because this page never fetches anything. A $ref cycle is cut and reported, since a recursive Avro type has to be written by hand. The generated schema is run back through our own Avro validator on every change, so anything unregistrable is reported here rather than by the registry.
Related kafka tools
Kafka JSON to Avro Schema What JSON cannot tell you Kafka Protobuf to Avro Schema What does not survive the conversion Kafka Avro JSON Converter Why the console producer rejects your line Kafka Protobuf JSON Converter Why your JSON does not round-trip Kafka Avro Schema Validator The defaults Avro accepts and rejects Kafka Schema Compatibility Checker What the registry will say, before you ask it
All 73 kafka tools