JSON to Protobuf (.proto) Schema

Paste any JSON document and get a valid .proto file (proto3 syntax). The generator walks the object, infers each field’s type, and emits nested message definitions for sub-objects plus repeated fields for arrays. Useful as a starting point when adding Protocol Buffers to a system that currently speaks JSON.

How to use the JSON to Protobuf (.proto) Schema

Paste one representative record. Set the root message name (the type for the top-level object) and a package name. The generator emits a .proto file with the syntax line, package declaration, and one message per nested object. Field numbers start at 1 and increment in field-order — review and adjust before checking into production: once a number ships, it’s frozen.

Type inference: integers become int32 (or int64 if any value exceeds 32-bit range), fractional numbers become double, booleans become bool, strings become string. Arrays become repeated. Nested objects become nested messages named after the field key.

About JSON to Protobuf (.proto) Schema

Protocol Buffers is Google’s contract format for structured data — the schema lives in a .proto file and both client and server compile it to language-native types. Compared to JSON it’s smaller on the wire, faster to (de)serialise, and statically typed; the cost is the schema-first workflow. Existing JSON APIs that want to add proto support typically start by writing the .proto by hand based on observed payloads. This generator does the rote part — inferring the message shape and field types — so you can focus on the design choices that matter: field numbers (which are forever), nullable semantics (proto3’s default is implicit defaults; proto2 has explicit optional / required), and which sub-objects deserve to be separate types vs inline.

The output is intentionally minimal. There are no service / RPC definitions, no streaming markers, no oneof groupings — just the data shape. Add those manually based on what your RPCs need. Field numbers start sequentially; for production schemas, allocate ranges thoughtfully (typically 1-15 for the most common fields, since they encode in one byte).

Common use cases

• Adopting gRPC over a REST API — generate the .proto from existing responses as a starting point.
• Schema documentation — publish a .proto alongside your JSON API so consumers have a typed reference.
• Cross-language data exchange — protobuf reads identically in Go / Java / Python / Rust, useful for polyglot pipelines.
• Validating field-name compatibility — generate today, regenerate after a payload change, diff to catch breakages early.