What does this JSON to Proto converter do?
This tool infers a Protocol Buffers (.proto) schema from sample JSON. Use the output as a starting point for a proto3 message, then rename types and tighten field types before you register it. The structure comes from the JSON you paste; nested objects become nested messages.
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 Protobuf, JSON Schema, or enums. Parsing runs in your browser; the JSON is not uploaded.
Why the .proto looks different from your JSON
Inference picks a proto3 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 became user_id | Proto field names are snake_case. proto3 JSON still accepts userId unless two keys collapse to the same name; then the second becomes user_id_2 and will not round-trip the original key. |
A quoted number such as "1999" became int64 | Digit-only strings that fit signed 64-bit range become int64. Larger digit strings stay string. Change the type if the value is really a string ID. |
An unquoted integer became int32 or int64 | Values that fit 32-bit signed range become int32; larger integers become int64. Non-integers become double. |
A date-time string became google.protobuf.Timestamp | RFC 3339 strings such as 2024-01-01T00:00:01Z map to Timestamp. A 1.5s string maps to Duration. Keep them as string if they are not those types. |
Nested objects became nested messages named Customer or Item | Each object field gets a PascalCase message. Repeated object arrays use a singular name when the key ends in s. Rename to match your domain. |
A nested array became a message with values | Proto3 cannot nest repeated directly, so [[1,2],[3,4]] becomes repeated Matrix with repeated int32 values. Reshape the JSON to match before you use the schema, for example {"matrix":[{"values":[1,2]},{"values":[3,4]}]}. |
The root type is Root | The converter always emits one top-level Root message. Rename it before you register the schema. |
Objects are inferred as messages, not map fields. A single ALL_CAPS string is still string, not an enum. Edit those by hand if you need maps or enums.
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 .proto | That value was null or [], so no type could be inferred | Give the field a concrete sample value and convert again |
A reserved name became message_field | message, syntax, and other proto keywords cannot be field names | Rename the field in the schema if you need a different identifier |
| 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 .proto is a draft schema, not a payload. Producing Protobuf to Kafka still requires this schema (or an equivalent) to be registered, plus a serializer that encodes JSON or typed fields into Protobuf 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.