Protocol Buffers Decoder

What a schema-less Protobuf decoder can prove

Protocol Buffers stores a sequence of field tags and values, not the original .proto declarations. The official protobuf encoding guide defines each tag by shifting the field number three bits and combining it with the wire type, equivalent to field_number × 8 + wire_type. That lets this decoder prove the field number, wire type, byte boundaries and the encodings that are structurally possible. It cannot prove whether a varint was declared as uint64, int64, sint64, bool or an enum, because those declarations can share the same bytes.

The input mode is always explicit. Hex accepts ASCII whitespace and at most one leading 0x. Base64 and Base64URL are validated separately, including length, padding and unused pad bits; standard and URL-safe alphabets cannot be mixed. Raw text means the exact UTF-8 bytes produced by the browser’s TextEncoder, backslash escapes are not interpreted. File input uses the file’s exact bytes.

Wire types and interpretations

JavaScript’s ordinary number type cannot exactly represent every 64-bit integer. This decoder uses BigInt throughout the wire parser and converts exact integers to decimal strings for display and export. Special floating-point values such as NaN, infinities and negative zero are also exported as strings so JSON does not silently turn them into another value.

Understanding length-delimited ambiguity

Wire type 2 is used for strings, raw bytes, embedded messages and packed repeated scalar values. Without a schema, a byte sequence may be valid in several of those roles simultaneously. For example, 2a 03 01 02 03 is field 5 containing three bytes. Those bytes are valid packed varints [1, 2, 3], but they are also ordinary bytes. The decoder displays both candidates and does not rank one as more likely.

A nested-message candidate appears only when the entire length-delimited body parses as a complete message. Packed varint, fixed32 and fixed64 candidates likewise appear only when all bytes are consumed under that interpretation. A strict UTF-8 candidate requires the complete sequence to decode without replacement characters. These checks show structural possibilities, not the field’s declared type.

Groups are handled according to the wire grammar even though modern schemas usually prefer embedded messages. A start-group tag must close with an end-group tag carrying the same field number. A root-level, mismatched or missing end tag stops decoding at the exact byte offset. Fields decoded before the failure remain visible; missing bytes and unknown values never become a fake zero.

Limits, framing and safe handling

The decoder accepts one unframed message up to 10 MiB. It does not split a length-prefixed stream, gRPC frame, delimited-message file or transport envelope. Remove that framing first, then decode one message. The parser also caps total records, recursive depth, visible rows and candidate work. These controls follow the spirit of the official guidance on large data sets and implementation limits: protobuf is efficient, but a diagnostic browser tab still needs bounded memory and work.

Field numbers must be between 1 and 536,870,911. The decoder warns about 19,000–19,999 because the official field-number guidance reserves that implementation range. Wire types 6 and 7 are invalid.

Parsing and exporting happen locally. The multi-step view may keep a bounded payload in this tab’s sessionStorage for up to two hours; starting over removes it. Nothing is placed in the URL or sent to our servers. JSON output is explicitly a decode report in this tool’s own format, not ProtoJSON. CSV starts with a UTF-8 BOM and prefixes formula-like cells for safer spreadsheet opening. Reports can still contain confidential application data, so inspect them before sharing.