🧬 Protobuf Decoder (decode_raw)
Paste protobuf bytes (hex or base64) to decode the message into its fields — numbers, wire types and values, with nested messages expanded.
Decoded fields
Paste a Protocol Buffers message as hex or base64 to decode its structure — like protoc --decode_raw. The wire format is self-describing for field numbers and types, so you get each field's number, wire type and the plausible readings of its value (a length-delimited field is shown as a nested message when it parses, otherwise as a string or raw bytes). Without the .proto schema, field names and exact types (int vs sint, string vs bytes) can't be recovered — that's a property of the format, not a limit of the tool. 🔒 Decoded entirely in your browser.
How the protobuf decoder (decode_raw) works
Protocol Buffers encode each field as a varint "tag" that packs the field number and a wire type, followed by the value. Because that structure is self-describing, you can decode a message without its .proto schema — exactly what protoc --decode_raw does. This tool reads the bytes (hex or base64), walks the fields, and for each shows the field number, the wire type (varint, 64-bit, 32-bit or length-delimited) and the plausible readings of the value: a varint as unsigned, zigzag-signed and boolean; fixed 32/64-bit as integer, float/double and hex; and a length-delimited field as a nested message when its bytes parse cleanly, otherwise as a UTF-8 string or raw bytes. It uses BigInt so 64-bit values stay exact.
What a schema-less decode cannot recover is the field names and the exact declared types — protobuf does not store them in the message, so field 1 is "1", not "userId", and a length-delimited field could be a string, bytes or a sub-message. The tool makes the standard best-guess (nested message first, then string) just like decode_raw; treat the readings as candidates, not certainties. This is genuinely useful for inspecting an API response, a gRPC payload or a COSE/WebAuthn structure when you don't have the .proto handy. Everything is decoded in your browser, so the payload — which may be sensitive — is never uploaded.
Frequently asked questions
Can I decode protobuf without the .proto file?
Yes — that's exactly what this does. The wire format encodes each field's number and type, so the structure and values decode without a schema. You just won't get the human-readable field names or the exact declared types, which aren't stored in the message.
What is protoc --decode_raw?
A protobuf command that dumps an unknown message's fields by number and wire type without a schema. This tool is a browser equivalent: paste the bytes as hex or base64 and get the same field-by-field breakdown, with nested messages expanded.
Why is a field shown as a number instead of a name?
Because protobuf messages carry only field numbers on the wire, not names — names live in the .proto schema, which isn't transmitted. Without that schema, field 1 can only be shown as "1". Match the numbers to your .proto to recover the meaning.
How do I know if a value is a string or a nested message?
Length-delimited fields (wire type 2) can be strings, raw bytes or embedded messages, and the wire format doesn't distinguish them. The tool tries to parse the bytes as a nested message first (as decode_raw does) and falls back to a UTF-8 string or hex — so the reading is a best guess.
Can I paste base64 as well as hex?
Yes — paste the message as spaced or unspaced hex (with or without 0x), or as standard/URL-safe base64. The tool detects the format and decodes it the same way.
Is my payload uploaded?
No — decoding runs entirely in your browser with no network calls, so an API or gRPC payload never leaves your device. It works offline too.