We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Free online JSON to Protobuf converter. Instantly generate Protocol Buffers message definitions from JSON data.
Automatically convert camelCase to snake_case, following Protobuf style guidelines.
Enter JSON to generate the corresponding .proto file structure.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
This JSON to Protobuf converter turns a JSON object, or an array of objects, into editable .proto message text. A .proto file describes a message's fields and types. The result is a starting schema, not a Protobuf binary payload and not generated application code.
Scalar values guide the inferred types: booleans become bool, whole numbers become int32 or int64 based on their range, decimal numbers become double, and strings become string. Nested objects become nested messages. Arrays become repeated fields. The tool emits a syntax declaration and can optionally include a package declaration.
The output reflects the values present in the sample, not a complete business contract. A field observed as an integer may later exceed that range, and a sample cannot establish whether a value is required, nullable, or absent in other records. For an input array, only its first object contributes fields. For an array-valued field, only its first element guides the inferred type or nested shape.
Field tags are assigned sequentially within each message, starting at 1 in the order the input keys are visited. Protobuf uses these numbers to identify fields in encoded messages; they matter for compatibility after a schema is in use. Review the assigned tags against your existing schema before adopting the result.
| Sample JSON value | Generated declaration | What to review |
|---|---|---|
true or false | bool | Confirm the field has no additional domain meaning. |
| Whole number | int32 or int64 | Check the full allowed range and whether signedness or another numeric type is needed. |
| Decimal number | double | Check whether floating-point representation suits the value. |
| String | string | Dates and identifiers remain strings unless you redesign their representation. |
| Object | Nested message | Check the generated message name and whether fields vary across records. |
| Array | repeated field | Check element consistency; the first element determines the inferred type. |
A null value is represented as a string field with a source-null comment, while an empty array becomes repeated string with a comment. These are placeholders chosen because the sample supplies no usable type information; they do not assert that string is the correct application-level type.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Paste valid JSON. Use an object, or an array whose first item is an object. The example control can fill in a nested sample to show the output format.
Enter a root message name; it is normalized to PascalCase. Add a package name only if your schema needs one. Choose proto2 or proto3 syntax and switch snake_case field naming on or off to match your project convention.
Review nested messages, scalar types, repeated markers, comments for null or empty arrays, and the sequential field tags. Invalid JSON or an unsupported root value produces an error instead of a definition.
Copy the text into your schema workflow and compile it with the Protobuf tooling used by your project. Check it against representative records and existing field numbers before generating language bindings or using it in a released interface.
Use cases
See how the tool fits into real work and everyday tasks.
A developer can paste a representative response object to sketch nested messages and repeated fields, then compare the draft with other responses before adopting it.
An integration team can use one captured event as a first pass at a message structure. Include a typical object and then manually account for optional fields and event variants that the sample does not show.
A learner can change root naming, syntax, and field-name style to see how the same JSON example maps into message declarations, while keeping the distinction between schema text and encoded data clear.
Q&A
Find concise answers to common questions and confusing cases.
No. It produces readable .proto message-definition text from JSON values. Binary serialization requires a schema and the appropriate Protobuf runtime or generated code.
No. For a root array, only the first item is used to infer the message. For an array field containing objects, only its first object is used to infer the nested message. Compare additional samples yourself to find missing or inconsistent fields.
An empty array contains no example element from which to infer a type. The output uses repeated string as a marked placeholder; change it to the type defined by your data contract.
They are sequential draft tags based on the current key order. Check every tag against your existing schema and compatibility policy. Once used, field numbers should not be repurposed or reused.
JSON null does not identify the field's intended Protobuf type, so the draft uses a string placeholder and adds a comment. Choose the real type and presence behavior from your application contract.
Notes
Review scope, result limitations, and important precautions before use.
A single sample cannot establish optionality, null semantics, validation rules, enums, numeric limits, or every shape that production records may contain. Large JSON numbers can also lose exactness in common processing environments; if an identifier must preserve every digit, supply it as a string in the sample and choose its schema representation deliberately.
Do not publish these inferred field numbers as a replacement for an established Protobuf contract without checking compatibility. The converter displays the generated text but does not compile the schema or validate it against your full dataset. Test the edited definition with the project compiler and representative records.
Related
Discover related tools, collections, and available API capabilities.