Protobuf Decoder

No — that's the whole point. It decodes the raw wire format directly, the same way protoc --decode_raw or protoscope do, using only the field numbers and wire types the bytes themselves carry.

Because the wire format genuinely can't say which one is correct without the .proto schema. A wire type only narrows things down to a category (e.g. "varint") — it doesn't distinguish a uint32 from an int32 from a bool from an enum, all of which encode as the exact same bytes. Showing every plausible reading honestly, rather than guessing one, avoids presenting a guess as a fact.

Plain two's-complement and zigzag are two different ways protobuf can represent a negative number, and they produce different results for the same bytes. Regular int32/int64 fields use two's-complement (which is why small negative numbers encode as huge varints). sint32/sint64 fields specifically use zigzag encoding instead, precisely so small negative numbers stay small on the wire. Both interpretations are shown since the wire type alone doesn't say which one a given field actually is.

A length-delimited field's bytes are also recursively run back through the same decoder. If that recursive parse succeeds and finds at least one real field, it's shown as an expandable nested message alongside the string/bytes readings. It's only kept when it actually produced a field — this avoids falsely showing "nested message" structure on bytes that just happen, by chance, to look decodable (any 2-bit wire type is technically "valid" for some interpretation, so pure text or opaque bytes can occasionally coincidentally parse).

It's only shown when the bytes are genuinely valid UTF-8 (a strict decode is used, not a lossy best-effort one) — for a field that's actually binary data, not text, forcing a UTF-8 reading would just show mangled garbage, so it's left out and only base64/hex are shown.

Yes, recursively, up to a reasonable nesting depth — deeper than that is vanishingly rare in real protobuf messages and is capped as a safety guard against genuinely malformed or adversarial input.

Base64 (the most common copy-paste form for protobuf bytes) or hex, with a toggle to switch between them. Hex input tolerates spaces between byte pairs.

It shows a clear error explaining what went wrong (e.g. a truncated field, an invalid length) rather than a blank result or a crash.

No — decoding happens entirely in your browser. Nothing you paste is sent to a server.

No — field NAMES and true semantic types don't exist in the wire format at all, only in the .proto schema, so there's nothing in the raw bytes to generate a meaningful .proto from. If you're starting from JSON instead and want to generate code, try the JSON to Class Generator.

Manually, you'd read the first varint of each entry as a tag, split it into a field number and a wire type (`tag = (field_number << 3) | wire_type`), then decode the value according to that wire type. This tool automates exactly that process — paste your bytes and every field is broken out and decoded for you, with every interpretation its wire type allows shown side by side.

It's a compact, fast binary format for serializing structured data, created by Google — you define a message's shape once in a `.proto` file, then generate strongly-typed code to read and write that format in almost any language. It's most commonly seen powering gRPC services, but it's used anywhere a smaller, faster, cross-language alternative to JSON is worth the trade-off of no longer being human-readable without a decoder like this one.

No — they're related but different. gRPC is a remote-procedure-call framework (how services talk to each other over the network); Protobuf is the data-serialization format gRPC uses by default for its messages. Protobuf works entirely on its own, with no gRPC involved at all — that's exactly what this tool does: decoding raw protobuf bytes with no RPC framework, service, or gRPC connection anywhere in the picture.

There's no universal "better" — different trade-offs for different jobs. Protobuf typically produces the smallest, fastest-to-process messages (commonly ~20-30% smaller than Avro's, and several times smaller than JSON's for the same data) and is strongly typed via its schema, but isn't human-readable without a tool like this one. Avro also uses a schema, but usually paired with a schema registry so each message only carries a compact schema ID rather than repeating field info — a different approach to the same efficiency goal, common in Kafka pipelines. JSON wins when human-readability and zero schema setup matter most, at the cost of size and speed.

No — this tool only decodes existing protobuf bytes; it doesn't encode JSON (or anything else) into protobuf. That direction is a fundamentally different, harder problem: turning JSON into valid protobuf bytes requires knowing the real field numbers and wire types for each key, which only exist in the actual `.proto` schema — there's no way to infer them from JSON data alone the way this tool can decode bytes without one.

Protobuf's own documentation recommends keeping individual messages under about 1MB as a soft guideline (not enforced), most implementations refuse to parse anything over roughly 64MB by default, and every implementation shares a hard ceiling of just under 2GiB baked into the format itself. The real reason to stay well under all of these: protobuf can't "seek" inside a message, so the whole thing has to load into memory at once — the practical advice for genuinely large data is to split it into many smaller messages rather than one giant one.

Google created and open-sourced it, and yes — it's extremely widely used today, most visibly as gRPC's default message format, but also directly in countless internal and public APIs across the industry that have nothing to do with gRPC at all.

At the schema level: scalar types (int32, int64, uint32, bool, string, bytes, float, double, and more), nested message types, repeated fields (lists), and enums. On the wire — which is all this decoder ever sees, since it has no schema — those collapse into just 4 wire types: varint (covers int32/int64/uint32/uint64/sint32/sint64/bool/enum, which is why a varint field shows several possible readings at once), 64-bit fixed (fixed64/sfixed64/double), 32-bit fixed (fixed32/sfixed32/float), and length-delimited (string/bytes/embedded messages).