What does this JSON to Avro converter do?
This tool infers an Avro schema from sample JSON. Use the output as a starting point for a record schema, then rename types and tighten field types before you register it. The structure comes from the JSON you paste; nested objects become nested records.
The schema is a guess from one document, not a complete domain model. Null fields and empty arrays are omitted because their type cannot be inferred. The tool does not emit binary Avro, Avro IDL, or enums. Parsing runs in your browser; the JSON is not uploaded.
Why the Avro schema looks different from your JSON
Inference picks an Avro type and a legal field name for every key. These changes are converter choices, not a failed parse.
| What you see | Why, and whether to change it |
|---|---|
userId stayed userId | Avro field names keep camelCase. Names that are not valid identifiers are rewritten, and colliding names get a suffix such as user_id_2. |
A quoted number such as "1999" stayed string | Avro JSON encodes integers as numbers, so a quoted digit string is a string. Change the type if the value is really an int or long. |
An unquoted integer became int or long | Values that fit 32-bit signed range become int; larger safe integers become long. Non-integers become double. |
| A nested array stayed an array of arrays | Avro allows nested array types, so [[1,2],[3,4]] becomes an array whose items are arrays of int. |
| Mixed array values became a union | [1, "a"] becomes ["int", "string"]. Compatible numbers widen instead of forming a union. |
A field on only some array items became ["null", int] | Fields missing from some objects are optional with default null, so every item still encodes. |
The root type is Root | The converter always emits one top-level Root record. Rename it before you register the schema. |
Objects are inferred as records, not map fields. A single ALL_CAPS string is still string, not an enum. Edit those by hand if you need maps, enums, or logical types.
Missing fields or conversion errors
If a field is missing from the schema, or the editor shows an error, use the row that matches what you see.
| What you see | Cause | What to do |
|---|---|---|
| Invalid JSON near a token | The input is not valid JSON | Fix the syntax, then wait for the schema to regenerate |
| JSON root must be an object or an array | The document is a string, number, boolean, or null | Wrap the value in an object, for example { "value": … } |
| A key from the JSON is missing in the schema | That value was null or [], so no type could be inferred | Give the field a concrete sample value and convert again |
| JSON nesting exceeds 32 levels | Objects or arrays are nested deeper than the converter allows | Flatten the document, or convert a smaller sample |
Use the schema in a Kafka producer
The generated Avro schema is a draft, not a payload. Producing Avro to Kafka still requires this schema (or an equivalent) to be registered, plus a serializer that encodes JSON or typed fields into Avro bytes. Pasting the schema text into a topic does not send a message.
In Kafma Schema Explorer register the subject and version, then generate or edit a payload in the Kafka Console and produce it. Tighten types and names before you publish; this page’s guesses may not match the schema you already use in production.