Json to Protobuf

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Json to Protobuf

JSON to Protobuf infers a draft Protocol Buffers message declaration from example JSON objects. Example data reveals values, not a complete schema contract. The generated declaration can help start a design, while stable field numbering, optionality, repeated values, integer ranges, and backward compatibility require deliberate decisions before the schema is used by multiple systems. Code transformations are most useful when you know the language and the surrounding context of the snippet. Work from a saved copy and start with a small, valid example that demonstrates the behavior you need. Formatting, encoding, and generation do not establish that a program is correct. Review the output as source code, keep meaningful comments when appropriate, and test the result in the same environment that will eventually interpret it. This makes subtle changes much easier to spot.

Guide updated October 13, 2026

How to use this tool

1. Paste a small, representative snippet and keep a copy of the input. Include the punctuation and delimiters needed to make the example meaningful.
2. Paste representative JSON, generate the declaration, and review inferred field names, types, and nested message structure.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Copy the result into a scratch file and verify it with the intended parser, editor, or test environment before replacing the original code.

SEE IT IN PRACTICE

A worked example

{"name":"Ada","active":true}

A draft message with a string-like name field and a boolean active field

The example provides evidence for two value types, but additional records may reveal nulls, missing fields, or other values the sample did not show.

Samples cannot define the whole contract

A JSON number does not reveal whether the intended value is a bounded integer, a floating-point measurement, or an identifier that should be textual. An empty array reveals no element type, and a missing field may indicate optionality rather than absence from the schema. Use several representative records and document decisions the generator cannot infer. Nested objects and repeated values deserve explicit review before the declaration becomes a shared interface between services.

Field numbers are compatibility decisions

Protocol Buffers field numbers are part of the serialized contract, not cosmetic numbering for a source file. Once a schema is in use, changing or reusing numbers can make old and new messages incompatible in subtle ways. Review the draft before assigning it that long-term role. Compile the schema with the target toolchain and test both serialization and deserialization of boundary cases. A generated declaration is a starting design aid; versioning, reserved fields, and evolution policy still need deliberate ownership.

When this tool is useful

• Draft a message schema from sample data
• Explore nested object mappings
• Review an API's likely field types before formal schema design

Tips for a better result

• Review every inferred type and field number, then compile the schema and test representative messages in the intended language tooling.
• Separate a syntax check from a behavior check. A snippet can parse successfully while producing the wrong value, selecting the wrong element, or changing an important edge case.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions