Field name casing
Protobuf JSON uses lowerCamelCase by default, so email_address becomes emailAddress
{"id":1,"email_address":"a@b.com"}
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.
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.
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.
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.
Protobuf JSON uses lowerCamelCase by default, so email_address becomes emailAddress
{"id":1,"email_address":"a@b.com"}Proto3 JSON leaves scalar defaults out entirely, which is not the same as null
{"id":0,"emailAddress":""}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
int64 and uint64 are encoded as STRINGS in canonical protobuf JSON, because JSON numbers lose precision above 2^53.
Instead:Parse them as strings.
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.
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.
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.
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.
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.
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.