Paste a Protocol Buffers message as hex or Base64 to see every field number, wire type and value, with nested messages, strings and packed numbers worked out automatically. Add your .proto file to get field names, enum names and correctly typed values.
Last updated:
Schema (.proto) optional, for field names
Advertisement
Advertisement
How to use the Protobuf Decoder
Paste the encoded message as hex or Base64, or upload the raw binary file. The format is detected automatically.
Read the tree: each line shows the field number, the detected type, the value and its byte offset.
Optionally add your .proto in the schema panel and pick the root message to see field names and enum values.
Strip a prefix if the bytes came from gRPC or a length-delimited stream.
Switch to JSON or decode_raw view and copy or download the result.
Each field begins with a tag, a varint equal to (field_number << 3) | wire_type. A varint stores 7 bits per byte, least significant group first, and the high bit of each byte says whether another byte follows. Take the bytes 08 96 01:
08 is the tag: 8 >> 3 = field 1, 8 & 7 = wire type 0 (VARINT).
96 01 is the value: 0x96 has the continuation bit set, so take its low 7 bits (0x16 = 22) and add the next byte shifted by 7 (1 × 128). The value is 150.
For a length-delimited field such as 12 07 74 65 73 74 69 6e 67, the tag 0x12 means field 2, wire type 2, and the next varint (7) is the number of data bytes that follow, here the UTF-8 text "testing". Common tag bytes worth recognising: 0a (field 1, LEN), 10 (field 2, VARINT), 12 (field 2, LEN), 18 (field 3, VARINT), 1a (field 3, LEN).
Tips for decoding real-world payloads
Base64 from JSON or logs: gRPC-Web, Firebase and many APIs Base64-encode protobuf bytes. Paste them directly; URL-safe Base64 with - and _ also works.
Length-prefixed streams: files written with writeDelimitedTo start each message with a varint length. Use the length-delimited skip option for the first message.
Negative int32 values are always encoded as 10-byte varints, so a long varint ending in 01 is usually a negative number; check the int64 reading.
Floats and doubles: a 32-bit or 64-bit field is shown as a float or double when the value looks like an ordinary number, otherwise as an unsigned integer, with the other reading listed next to it.
Proto2 vs proto3: both use the same wire format. Proto3 packs repeated numeric fields by default, and the decoder unpacks them whether or not they are packed.
Frequently asked questions
Can you decode protobuf without the .proto file?
Yes, partly. The binary format stores each field's number and wire type, so the structure, numbers and strings can always be recovered. What is lost without the schema are the field names and the exact types: a varint could be an int32, a bool, an enum or a ZigZag-encoded sint, so the decoder shows the likely readings side by side.
What are protobuf wire types?
Every field starts with a tag that holds the field number and a 3-bit wire type: 0 VARINT (int32, int64, uint, sint, bool, enum), 1 I64 (fixed64, sfixed64, double), 2 LEN (string, bytes, nested messages, packed repeated fields), 3 and 4 start and end group (deprecated proto2 groups) and 5 I32 (fixed32, sfixed32, float). The tag itself is the varint (field_number << 3) | wire_type.
How does the decoder tell a string from a nested message?
A length-delimited field can hold either. The decoder first checks whether the bytes are valid, printable UTF-8 text and shows them as a string; otherwise it tries to parse them as a message and only accepts the result if every byte is consumed by valid fields. If neither works it tries packed varints and finally shows raw bytes. When a string also parses as a message, that is noted so you can check with a schema.
What is ZigZag encoding?
sint32 and sint64 fields map signed numbers to unsigned ones so small negative values stay short: 0 becomes 0, -1 becomes 1, 1 becomes 2, -2 becomes 3, and so on, using (n << 1) ^ (n >> 63). Without it, a negative int32 or int64 always takes 10 bytes as a varint. The decoder shows the ZigZag reading of every varint as "sint".
How do I decode a gRPC message?
A gRPC message on the wire has a 5-byte prefix: one compression flag byte and a 4-byte big-endian length. Choose "gRPC frame" under Skip leading bytes to remove it. If the flag is 1 the payload is compressed (usually gzip) and has to be decompressed before it can be decoded.
Why are 64-bit numbers strings in the JSON output?
The proto3 JSON mapping writes int64, uint64, fixed64 and sfixed64 values as strings, because JavaScript numbers lose precision above 2^53. Without a schema, small varints are written as numbers and larger ones as strings for the same reason.
Is my data sent to a server?
No. The message and the .proto file are parsed by JavaScript in your browser tab. Nothing is uploaded, so you can safely inspect production payloads.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.