Protobuf Decoder

—

How to use it

1. Paste a protobuf payload as base64 (an API response, a gRPC frame body) or as hex bytes.
2. Leave the format on Auto detect or pin it to Base64 or Hex yourself.
3. Fields appear as a list: field number, wire type and decoded value, with nested messages indented.
4. For length-delimited fields the tool tries readable UTF-8 text first, then a nested message, and falls back to hex.
5. Use Sample to see a small message decoded, then Copy the report as plain text.

Common use cases

• Inspecting gRPC traffic — strip the 5-byte gRPC frame prefix, then paste the message body to see what a stub actually sent.
• Debugging service-to-service payloads — confirm which field numbers carry data when no .proto file is at hand.
• Reverse-engineering undocumented APIs — map field numbers and value shapes before writing your own schema.
• Teaching wire format — show how varint tags, zigzag-free integers and length prefixes sit on the wire.

Why it stays private

Decoding is pure byte slicing in your browser's memory. The payload is never uploaded, and with no schema involved there is nothing to look up remotely either.

FAQ

Q: Can it show the real field names? A: No. Field names live in a .proto file, which this tool deliberately does not use. You get field numbers, wire types and values, and you map names yourself.

Q: What are the limits? A: Wire types 3 and 4 (deprecated groups) are rejected with an error, packing detection is heuristic, and nested recursion stops at 8 levels. Length-delimited fields may also be ambiguous between text, nested messages and raw bytes.

Q: Does it validate the message against a schema? A: No. This is a raw wire-format reader, so a malformed payload fails at the exact byte where parsing becomes impossible, which is often all you need to locate corruption.