How can it decode Protobuf without the .proto schema?

The Protobuf wire format is self-describing enough to parse without a schema. Each field is a varint key holding the field number and wire type, followed by a payload. The tool reads those keys and shows every value the wire type could represent.

Why does one field show several interpretations?

Without a schema the tool cannot know whether a varint is an int, a zigzag sint, a bool or an enum, so it shows all of them. A 64-bit field is shown as fixed64, sfixed64 and double, and you pick the one that fits your message.

Does it decode nested messages?

Yes. Length-delimited fields are tried as embedded messages and decoded recursively when that succeeds, while also being offered as a UTF-8 string or raw bytes when those are plausible.

Can it recover the original field names?

No. Protobuf does not put field names on the wire, only numbers. You can recover field numbers, wire types and values, but names require the original .proto definition.

Is the payload uploaded anywhere?

No. Parsing happens entirely in your browser, which makes it safe to inspect captured API or gRPC traffic without sending it to a third party.

Protobuf Decoder (No Schema)

Protocol Buffers (Protobuf) is Google’s compact binary serialization format, used heavily in gRPC APIs and high-performance services. Normally you need the matching .proto schema to decode a message, but the wire format carries enough structure to parse without one. This tool reverse-engineers raw Protobuf bytes into field numbers, wire types and candidate values, which is invaluable when inspecting API traffic you do not have the schema for.

How it works

Every Protobuf field on the wire begins with a varint key that packs two pieces of information: field_number << 3 | wire_type. The wire type tells the decoder how to read the payload that follows:

Wire type 0 (varint) — covers int32, int64, uint, sint (zigzag-encoded), bool and enum. The tool shows the plain integer, the zigzag-decoded signed value, and a bool reading when the value is 0 or 1.
Wire type 1 (64-bit) — eight little-endian bytes shown as fixed64, sfixed64 and double.
Wire type 2 (length-delimited) — a varint length then that many bytes. This could be a UTF-8 string, raw bytes, an embedded message, or a packed repeated field, so the tool tries each.
Wire type 5 (32-bit) — four little-endian bytes shown as fixed32, sfixed32 and float.

Length-delimited payloads are recursively re-parsed as embedded messages, so deeply nested structures are revealed automatically.

Example

The hex 08 96 01 12 07 74 65 73 74 69 6e 67 decodes to two fields:

Field 1 (varint): 150
Field 2 (length-delimited): string "testing"

08 is the key for field 1, wire type 0; the varint 96 01 decodes to 150. 12 is the key for field 2, wire type 2; 07 is the length and the next seven bytes spell testing. Because there is no schema, field names are not recoverable — only numbers, types and values. Everything runs locally in your browser.