Protobuf Decoder — Protocol Buffer Wire Format Viewer

How to Use This Protobuf Decoder

1. Select your input format: Base64 (common for encoded payloads), Hex (from packet captures or debug output), or File (raw binary .bin or .pb files).
2. Paste your protobuf-encoded data into the input area, or drag and drop a binary file.
3. Click Decode to parse the wire format. The tool extracts field numbers, wire types, and raw values without needing a .proto schema.
4. Explore the decoded tree. Each field shows all possible type interpretations. Length-delimited fields are recursively decoded as potential nested messages.
5. Use Hex Dump view to see the raw bytes with each field highlighted in a different color. Click Export JSON to copy a JSON approximation of the decoded data.

What Are Protocol Buffers?

Protocol Buffers (protobuf) is a binary serialization format created by Google in 2001 and open-sourced in 2008. It provides a compact, efficient way to encode structured data that is 3-10x smaller and 20-100x faster to parse than equivalent XML. Protobuf is the backbone of Google's internal RPC systems and is the default serialization format for gRPC, one of the most widely adopted RPC frameworks in the industry.

Unlike JSON or XML, protobuf data is not human-readable. A .proto schema file defines the message structure, field names, and types. The schema is used at compile time to generate serialization code, but the encoded binary data only contains field numbers and wire-typed values — no field names, no type metadata. This is what makes protobuf compact, but also what makes it opaque without the original schema.

The Protobuf Wire Format Explained

Every protobuf message is a sequence of key-value pairs. Each pair starts with a tag — a varint that encodes both the field number and the wire type. The tag is computed as (field_number << 3) | wire_type. The wire type tells the decoder how to read the value that follows:

• Wire Type 0 (Varint) — Variable-length integer encoding. Used for int32, int64, uint32, uint64, sint32, sint64, bool, and enum. Small positive integers use just one byte. The sint types use zigzag encoding to efficiently represent negative numbers.
• Wire Type 1 (64-bit) — Fixed 8-byte value. Used for fixed64, sfixed64, and double. Always exactly 8 bytes, regardless of the value.
• Wire Type 2 (Length-delimited) — A varint length prefix followed by that many bytes. Used for strings, byte arrays, embedded messages, and packed repeated fields. This is the most versatile wire type — without a schema, the same bytes could be a UTF-8 string, a nested message, or raw binary data.
• Wire Type 5 (32-bit) — Fixed 4-byte value. Used for fixed32, sfixed32, and float. Always exactly 4 bytes.

Wire types 3 and 4 (start group / end group) were used in proto2 for grouping fields but are deprecated in proto3 and rarely encountered in modern systems.

Protobuf vs JSON

JSON is human-readable, self-describing (field names are in the data), and universally supported. Protobuf is binary, requires a schema for full decoding, and needs generated code or a decoder tool. However, protobuf messages are typically 3-10x smaller than equivalent JSON and 20-100x faster to serialize and deserialize. For high-throughput systems, APIs with strict contracts, or bandwidth-constrained environments (mobile, IoT), protobuf is often the better choice.

A key difference: JSON is self-describing — you can always read it. Protobuf without a schema gives you field numbers and raw values but not field names or semantic types. That is exactly what this tool provides: a best-effort decoding that shows all possible interpretations of each field.

Common Use Cases for Protobuf Decoding

• Debugging gRPC services — Inspect request and response payloads captured from network traces or proxy tools like Envoy, mitmproxy, or Wireshark.
• Reverse engineering APIs — Analyze protobuf-encoded data from mobile apps or services without access to the .proto schema.
• Validating serialization — Verify that your protobuf encoding library produces the expected wire format output.
• Log analysis — Decode Base64-encoded protobuf payloads commonly found in application logs and message queues like Kafka or Pub/Sub.
• Protocol analysis — Examine binary protocols that use protobuf as their serialization layer, such as Tensorflow model metadata, Android app bundles, or Kubernetes API objects.

Understanding Varint Encoding

Varints are the most common encoding in protobuf. Each byte uses 7 bits for data and 1 bit (the MSB) as a continuation flag. If the MSB is 1, more bytes follow. The value 300, for example, encodes as AC 02: the first byte 0xAC (10101100) has MSB=1 with data bits 0101100, and the second byte 0x02 (00000010) has MSB=0 with data bits 0000010. Combining in little-endian order: 0000010 0101100 = 100101100 = 300.

This encoding is efficient for small numbers (1 uses 1 byte, 127 uses 1 byte, 128 uses 2 bytes) but negative int32 values always use 10 bytes because they are sign-extended to 64 bits. That is why protobuf provides sint32 and sint64 types, which use zigzag encoding to map negative numbers to small positive varints: -1 becomes 1, 1 becomes 2, -2 becomes 3, and so on.

Related Tools

Protobuf payloads are often transmitted as Base64-encoded strings. Inspect JSON alternatives with the JSON Formatter. Verify data integrity with the Hash Generator. For gRPC metadata, decode JWT tokens with the JWT Decoder. Convert between data formats using the JSON-YAML Converter.