Generate Protobuf Schema
from JSON
Paste any JSON object and see the inferred data structure as TypeScript types — then use those types to write your proto3 schema. Works offline, no signup.
Open JSON to TypeScript ConverterFrom JSON to proto3 in four steps
No account. No upload. No nonsense.
No Server
Your JSON never leaves your device. There is no backend to send it to.
gRPC Ready
Generated type structures map directly to proto3 message definitions for gRPC services.
Works Offline
Load once and use forever — even on a plane or without internet access.
Related JSON tools
Common questions answered
What is Protocol Buffers (protobuf)?
Protocol Buffers is a language-neutral, platform-neutral serialization format developed by Google. Proto3 schemas define message types used by gRPC services and other high-performance APIs.
How do I map JSON types to proto3 types?
JSON strings map to string, integers to int32/int64, floats to float/double, booleans to bool, objects to nested messages, and arrays to repeated fields.
Does my JSON data leave my browser?
No. All processing is 100% client-side — your JSON never leaves your device.
Can I generate proto3 from complex nested JSON?
Yes. Use the TypeScript converter to infer the type structure, then map each TypeScript interface to a proto3 message definition.
What is the difference between JSON Schema and protobuf?
JSON Schema validates JSON documents at runtime. Protobuf defines binary message formats for efficient serialization — it is typically 3–10x smaller and faster than JSON for the same data.
Converting JSON to Protocol Buffers
Protocol Buffers (protobuf) is Google's binary serialization format used in gRPC microservices. Proto schemas (.proto files) define message types with numbered fields. This tool generates proto3 message definitions from JSON, mapping types to protobuf equivalents (string, int32, int64, float, double, bool) with field numbering.
The converter generates proto3 syntax with automatic field numbering. Nested objects become separate message types, arrays become repeated fields. Output includes syntax declaration, package suggestion, and import statements. Paste the result into a .proto file and compile with protoc.
{
"name": "Alice",
"age": 30,
"roles": ["admin"],
"address": {
"city": "Portland",
"zip": "97201"
}
}
syntax = "proto3";
message User {
string name = 1;
int32 age = 2;
repeated string roles = 3;
Address address = 4;
}
message Address {
string city = 1;
string zip = 2;
}
Get the most out of this tool
- Field numbers are permanent — never reuse or change a number in a deployed schema, even if you remove the field.
- Use int64 for ID fields to avoid overflow as data grows.
- Protobuf serializes to binary (10x smaller than JSON) — use for internal services, JSON for public APIs.
Ready to model your proto3 schema?
Free forever. No signup. Instant results.
Open JSON to Protobuf ConverterProtocol Buffers schema from JSON data
Protocol Buffers (protobuf) is Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. Where JSON is text-based and self-describing, protobuf is binary and schema-driven — the schema (.proto file) must be shared between producer and consumer. Protobuf messages are smaller and faster to serialize/deserialize than JSON for the same data, making them ideal for high-performance microservices communication via gRPC.
A .proto file defines message types and their fields. Each field has a name, type, and field number. The field number (not the name) is what appears in the binary encoding — this is why protobuf is backward-compatible: you can add new fields with new numbers without breaking old code. The converter generates proto3 syntax (the current version) with field numbers assigned in declaration order.
JSON type mapping to protobuf follows specific conventions. JSON strings map to proto string. JSON integers map to int32 or int64 depending on the expected range. JSON floats map to double or float. JSON booleans map to bool. JSON arrays map to repeated FieldType in protobuf. Nested JSON objects map to nested message types — each nested object gets its own named message type, and the parent message references it by name. JSON null is more complex: proto3 has optional keyword and Wrappers for nullable scalars.
Proto3 changed null handling from proto2. In proto3, fields have zero values by default — an unset string is "", an unset int32 is 0, an unset bool is false. This makes it impossible to distinguish "field is set to zero" from "field is not set". To represent nullable fields (like JSON null), proto3 offers two approaches: the optional keyword (which adds a has_field() accessor) or the google.protobuf.StringValue wrapper type (from google/protobuf/wrappers.proto), which is a message containing a single value field.
gRPC uses protobuf as its default serialization format. A gRPC service definition (in a .proto file) includes both the message types and the service interface with RPC method signatures. The converter generates only message definitions — you define the service interface separately. Once you have the .proto messages, protoc (the protobuf compiler) generates client and server code stubs in your chosen language: Go, Java, Python, C#, Node.js, Rust, Swift, and more.
JSON transcoding is a technique that allows a single gRPC service to also be accessed as a REST/JSON API. The transcoding rules are defined in the .proto file using the google.api.http option, specifying URL patterns and request/response mappings. Google Cloud Endpoints and gRPC-gateway implement this transcoding at the proxy level. When you generate a protobuf schema from JSON, you are building the foundation for a service that can serve both gRPC and REST clients.
When developers use this tool
Additional frequently asked questions
Why does protobuf use field numbers instead of field names?
Protobuf's binary format encodes field numbers, not names, making the serialized data extremely compact. This also enables backward compatibility: you can rename a field (the binary encoding stays the same) or add new fields with new numbers (old code ignores unknown field numbers). Field names only appear in the .proto schema and in generated code — never in the wire format.
Can protobuf represent all JSON data types?
Almost all. Strings, numbers, booleans, arrays, and nested objects all have direct protobuf equivalents. JSON null is the main challenge — proto3 uses zero values by default, not null. Use the optional keyword or Wrapper types (google.protobuf.StringValue) for nullable scalars. JSON's arbitrary object with unknown keys can be represented as google.protobuf.Struct, which is protobuf's equivalent of JSON object.
How much smaller is protobuf compared to JSON?
Protobuf is typically 3-10x smaller than equivalent JSON. The exact reduction depends on data characteristics: numeric-heavy data compresses more than string-heavy data (strings are stored as-is in both formats). After gzip compression, the difference narrows but protobuf still has an edge due to the binary encoding's structure. For high-frequency messages in microservices, the size reduction translates directly to lower latency and bandwidth cost.
Can I use protobuf without gRPC?
Yes. Protobuf is a standalone serialization format — gRPC uses it but does not own it. You can use protobuf with any transport: REST/HTTP, WebSockets, message queues (Kafka, RabbitMQ), file storage, or direct database storage. The protobuf library handles encoding/decoding; the transport is separate. Many teams use protobuf just for its binary serialization efficiency, without adopting gRPC.