JSON to Proto
Generate a protobuf (proto3) schema from JSON.
JSON to Proto – Generate a Protobuf Schema from JSON
The JSON to Proto converter infers a Protocol Buffers (proto3) schema from a sample JSON document. Paste an API response or a message payload and get .proto message definitions with typed, numbered fields — ready to adapt for gRPC services, Kafka topics, or any system that uses protobuf.
What it generates
syntax = "proto3";and an optionalpackagedeclaration.- A root message (name it yourself) with one field per JSON key, numbered in order.
- Nested messages for nested objects, named after their key in PascalCase (
customer→Customer). - repeated fields for arrays; arrays of objects get a message named after the singular key (
items→Item), merging the keys of all items. - Field names in
lower_snake_case, following the protobuf style guide. google.protobuf.Valuewith the matching import when a value isnullor an array has no usable type.
Type inference
| JSON value | Protobuf type |
|---|---|
"text" | string |
true / false | bool |
42 | int32 (or int64) |
3.14 | double |
{ … } | nested message |
[ … ] | repeated … |
Why start from JSON?
When you migrate a REST API to gRPC or add protobuf to an event stream, you usually already have JSON examples. Writing the matching schema by hand is tedious and easy to get wrong for large payloads. Generating it takes seconds and gives you a correct, consistent draft to refine.
Related tools
Make sure the sample is valid with the JSON Validator, or generate other formats with JSON to PHP Array and JSON to YAML.
Frequently Asked Questions
How are JSON types mapped to protobuf types?
Strings become string, true/false become bool, whole numbers become int32 (or int64 when large or when you switch it on), decimals become double, nested objects become their own message, and arrays become repeated fields of the item type. null or mixed arrays fall back to google.protobuf.Value.
Why are field names changed to snake_case?
The official protobuf style guide uses lower_snake_case for field names. Generated code converts them back to camelCase in languages like Java, Go, and JavaScript, and the JSON mapping of proto3 uses lowerCamelCase too, so "orderId" in JSON matches the field order_id.
Can the tool know which integers need int64?
Only from the example values. Numbers above 2,147,483,647 automatically become int64; for IDs and timestamps that may grow, turn on “Use int64 for integers” or edit the types by hand.
Is the generated schema final?
Treat it as a solid starting point. Review field numbers (they must never change once in use), consider enums for fixed string values, and use google.protobuf.Timestamp for date strings if you want typed timestamps.