Protobuf Decoder & Wire Inspector

Decode binary Protocol Buffer (.pb) files, Base64, or Hex into JSON, human-readable .pbtxt, or reverse-engineer a valid .proto schema. Color-coded byte wire inspector included.

Private by architecture: All processing is 100% client-side memory. Your data never leaves this browser tab.

Input Format:

Protobuf Raw Wire (Base64 or Hex)

0 bytes Base64 / Hex

Ready JSON

2-Way Protobuf Re-Encoder Edit fields in the JSON pane and download an updated .pb binary

Understanding Protobuf Binary Wire Format

Protocol Buffers serialize structured data into compact binary streams. Unlike JSON or XML, field names and whitespace are completely stripped during compilation and replaced by numerical field tags and 3-bit wire types.

🔍 Raw Wire Decoding

Even without the original .proto schema file, the wire format exposes field IDs, varints, strings, and submessages. This allows decoding gRPC payloads or binary dumps directly.

⚡ Reverse Engineering

The Inferred .proto generator inspects wire types and automatically generates an accurate Protobuf schema ready to compile in Go, Rust, or Python.

🔒 Total In-Browser Security

Private gRPC microservice traffic and confidential database BLOBs are decoded exclusively in browser memory. No data touches the wire.

Wire Type Reference Table

Every message field starts with a key encoded as (field_number << 3) | wire_type. The wire format recognizes the following physical types:

Wire Type	Type Name	Supported Data Types	Wire Layout
`0`	Varint	`int32, int64, uint32, uint64, sint32, sint64, bool, enum`	1 to 10 bytes using LEB128 bit-packing
`1`	Fixed64	`fixed64, sfixed64, double`	Exact 8 bytes (64 bits, little-endian)
`2`	Length-Delimited	`string, bytes, embedded message, packed repeated`	Varint length prefix followed by \(N\) data bytes
`3 / 4`	Groups	Start group / End group	Deprecated in Proto2, forbidden in Proto3
`5`	Fixed32	`fixed32, sfixed32, float`	Exact 4 bytes (32 bits, little-endian)

How LEB128 Varints Work

Little-Endian Base 128 allows integers to take variable width. The most significant bit (MSB, 0x80) indicates whether further bytes follow:

Byte 1: [1][0101100]  (MSB = 1: more bytes follow, value = 44)
Byte 2: [0][0000001]  (MSB = 0: terminating byte, value = 1)
Calculation: 44 + (1 << 7) = 44 + 128 = 172

For negative numbers, sint32 and sint64 use ZigZag encoding (n << 1) ^ (n >> 31) to map negative values to small positive integers, preventing standard two's complement 64-bit negative numbers from always consuming 10 bytes.

Schema-less Heuristic Submessage Detection

When our engine encounters a Length-Delimited field (Wire Type 2), it tests the payload with two competing heuristics:

UTF-8 String Test: If all bytes decode into valid printable UTF-8 characters without control sequences, it is formatted as a string.
Recursive Submessage Test: If the bytes cleanly unpack into valid tag/wire-type pairs where child field numbers are positive integers under 536,870,911 and sub-lengths match exactly with no leftover bytes, it is rendered as an embedded JSON object.

Frequently Asked Questions

Can you decode Protocol Buffers without the original .proto schema file?

Yes. The Protobuf binary wire format is structurally self-describing. Each field begins with a varint header containing the field number (tag) and a 3-bit wire type (0 for Varint, 1 for Fixed64, 2 for Length-Delimited, 5 for Fixed32). This allows parsers to navigate boundaries and extract numbers, strings, and submessages without prior schema knowledge.

What are the limitations of decoding Protobuf without a schema?

Field names and enum identifiers are stripped during compilation and do not exist in binary wire data. Furthermore, wire type 0 can represent int32, int64, bool, or enum, and wire type 2 can represent a UTF-8 string, raw byte buffer, packed repeated list, or embedded submessage. Our decoder uses structural heuristics to infer the most probable type.

What is LEB128 Varint encoding in Protocol Buffers?

Little-Endian Base 128 (LEB128) varints store integers using 1 to 10 bytes based on magnitude. The lower 7 bits of each byte store binary payload, while the most significant bit (MSB, 0x80) serves as a continuation flag. Integers below 128 occupy only a single byte, optimizing network payloads.

What wire types does Protobuf support?

Protobuf defines wire types: Type 0 (Varint: int32, int64, bool, enum), Type 1 (Fixed64: double, fixed64), Type 2 (Length-delimited: string, bytes, embedded submessage, packed repeated), Type 3/4 (Groups, deprecated in proto3), and Type 5 (Fixed32: float, fixed32).

Can I edit the decoded data and re-encode it back into a .pb binary file?

Yes. The 2-way re-encoder allows you to edit fields in the JSON editor and download an updated binary .pb file, Hex string, or Base64 payload without installing protoc.

About This Tool

Paste Base64 or Hex, or drop a raw .pb file, and this decoder walks the Protobuf wire format directly, reading tag/wire-type headers and LEB128 varints without needing the original .proto file. It outputs JSON, an inferred .proto schema, and TextProto, plus a byte-level wire inspector; an optional .proto schema drawer maps field numbers back to real names when you have one.

Since field names don't exist on the wire, type guesses (string vs. bytes vs. submessage) are heuristic, not guaranteed. If you only need to encode or decode a Base64 string with no Protobuf structure involved, use Base64 Converter instead.

Key Features

Schema-less decoding: infers field structure from the wire format alone, no .proto required.
Four output views: JSON, Inferred .proto, TextProto (.pbtxt), and a color-coded Wire Inspector table.
Optional .proto schema drawer: paste a schema to resolve field numbers to real field names.
File or text input: drag-and-drop a raw .pb binary, or paste Base64/Hex directly.
2-way re-encoder: edit the decoded JSON and export it back to Base64, Hex, or a binary .pb download.