Skip to content
AZ Tools

Protobuf Decoder (no .proto needed)

A protobuf payload gives up nothing on its own. There are no field names on the wire, only numbers and wire types, so an opaque body from a gRPC call or an API capture is unreadable unless you have the .proto that produced it — and when you are debugging someone else's service, you usually do not. This decoder reads the wire format directly. Every field comes back with its number, its wire type and its value, nested messages are expanded in place, and where the encoding is ambiguous it says so rather than picking for you. That ambiguity is real: a varint could be an unsigned integer, a signed zigzag one or a boolean, and a length-delimited field could be a string, a nested message, packed repeated numbers or raw bytes. The tool shows the reading it thinks is most likely and lists the others alongside. The guess for nested messages is not a guess about meaning — a run of bytes is only offered as a message when it parses cleanly as one, with every key a valid field number and every length landing exactly at the end. Everything runs in your browser; the payload is not uploaded.

Paste a base64 or hex protobuf payload to decode it.

How to use

  1. Paste the payload as base64 or hex — the format is detected, and you can force it.
  2. Read the tree: each line is the field number, the wire type and the value.
  3. Check the grey text for the other readings a value could have.
  4. Nested messages are indented under their parent field.
  5. Drop a binary file to decode a captured body straight from disk.

Frequently asked questions

Why are there no field names?
Because they are not transmitted. Protobuf puts only a field number and a wire type on the wire, and the names live in the .proto file at both ends. That is what makes the encoding compact, and it is why any schema-less decoder can show you the shape of a message but not what its fields are called.
How does it know a field holds a nested message?
It tries to parse the bytes as one and accepts the result only if it is fully consistent — every key a valid field number and wire type, every length ending exactly where the buffer does. Short strings sometimes pass that test by chance, so when the bytes are also valid text the tool says the reading is ambiguous.
What are the alternative readings for a number?
A varint on the wire could be an int32/int64/uint, a zigzagged sint, or a bool. A fixed64 could be a double, a fixed64 or an sfixed64. Nothing in the payload distinguishes them, so the most common reading is shown first and the others next to it.
Can it decode gRPC bodies?
A gRPC frame adds a one-byte compression flag and a four-byte length before each message. Strip those five bytes and the rest decodes here. Compressed frames have to be inflated first.
What about groups?
Groups are the deprecated wire types 3 and 4 from proto2 and are almost never seen. The decoder reports the marker where it finds one rather than guessing at the nesting.
Is my payload uploaded?
No. The bytes are decoded in your browser and nothing is sent to a server.

Related tools