Field name casing
Protobuf JSON uses lowerCamelCase by default, so email_address becomes emailAddress
{"id":1,"email_address":"a@b.com"}Kafka Protobuf JSON Converter
Check a JSON document against a .proto and get the canonical
proto3 form back. The differences that bite are named individually: a 64-bit
integer written as a number, a field written with its proto name, a value an
unsigned field cannot hold.
A type behind an import has to be pasted in alongside:
this page reads one file. The google.protobuf.* well-known
types are built in and still need their import line, the
way protoc requires.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Default values omitted
Proto3 JSON leaves scalar defaults out entirely, which is not the same as null
{"id":0,"emailAddress":""}Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Expecting snake_case in the JSON
Canonical protobuf JSON uses lowerCamelCase, so email_address becomes emailAddress. Most libraries accept both on input and emit camel.
Instead:Configure the printer if you need original names, and be consistent.
Reading an absent field as null
Proto3 JSON omits scalar defaults entirely. An absent field means zero, empty or false, not null.
Instead:Use wrappers or optional if you need to distinguish.
Assuming 64-bit ints stay numbers
int64 and uint64 are encoded as STRINGS in canonical protobuf JSON, because JSON numbers lose precision above 2^53.
Instead:Parse them as strings.
The canonical JSON mapping is not the JSON you would have written
Protobuf specifies exactly one JSON form, and a Java service using JsonFormat, a Confluent JSON converter and a Go service all emit that one. Hand-written documents rarely match it, and the mismatches are quiet.
Sixty-four-bit integers are quoted strings
int64, uint64, sint64, fixed64 and sfixed64 all serialise as JSON strings. Thirty-two-bit types stay numbers. The reason is that a JSON number is an IEEE 754 double, which holds integers exactly only to 2^53, and a protobuf int64 runs to 9223372036854775807. A consumer that expects a number gets a string; a producer that writes a number loses precision above 9007199254740991 without any error at all. This page names every field where that applies.
Field names are lowerCamelCase, by a rule with a twist in it
protoc derives a JSON name for every field by removing underscores and capitalising what follows, so field_with_underscores becomes fieldWithUnderscores. The twist is that it does not lowercase the first letter, so a field named FooBar stays FooBar rather than becoming fooBar. A parser accepts the original proto name as well, which is why a document written with proto names appears to work and then does not round-trip.
Default values are absent, and that is not the same as null
A singular proto3 scalar holding its default is not written at all: a false bool, a zero int, an empty string are all simply missing from the document. There is no null and no key. Anything that has to tell unset from zero, a patch, a nullable column, a partial update, cannot, unless the field is declared optional. A field that is optional, or a oneof member, or a message, does have presence and does appear even at its default.
The well-known types have their own forms
Timestamp is an RFC 3339 string with zero, three, six or nine fractional digits and never any other number. Duration is a string of seconds ending in s, with the same fractional rule. The wrapper types collapse to their bare value and still appear when holding zero, because having presence is their whole purpose. FieldMask is the surprise: it is a single comma-joined string and its paths are camel-cased too, so a path written c_d comes out as cD.
What this cannot see
Anything in another file. This page reads one .proto, so a type behind an import has to be pasted in alongside. It also cannot check a custom option: (google.api.http) and the like are extensions defined in files it cannot read, so their presence is reported as unverified rather than judged either way. Enum values are checked against the enum in this file, and proto3 enums are open, so an unrecognised number is preserved rather than rejected.
Related kafka tools
Kafka Protobuf to Avro Schema What does not survive the conversion Kafka Avro JSON Converter Why the console producer rejects your line Kafka JSON Schema to Avro What does not survive the conversion Kafka mTLS Config Generator The certificate is the identity Kafka Protobuf Binary Decoder Works without the .proto Kafka Partition Reassignment Generator The throttle is not optional
All 73 kafka tools