Debug gRPC

gRPC Response Decoder

Decode gRPC response payloads in the browser by providing the .proto schema and pasting the Base64 or binary body from your debugging tools, proxies, or logs.

gRPC body decodingBase64 and binary inputNo grpcurl required

Decode gRPC responses without a local CLI setup

gRPC uses protobuf as its default serialization format, which means response bodies captured from proxies, load balancers, or browser DevTools arrive as opaque binary or Base64 blobs. Decoding them typically requires grpcurl, a compiled client, or a reflection-enabled server. This page removes that friction by letting you paste the .proto schema and the response body directly in the browser — no CLI installation, no server access, and no compiled stubs.

The workflow is designed for the debugging scenario where you have a captured response and need to verify its contents quickly. Whether the payload came from an Envoy access log, a Charles Proxy export, a Wireshark capture, or the Network tab of a gRPC-Web application, you can decode it here as long as you have the matching .proto definition.

Handling the gRPC framing layer

A raw gRPC response over HTTP/2 includes a 5-byte frame prefix: one byte for the compression flag and four bytes for the message length. If your captured payload includes this prefix, you need to strip it before decoding. The first byte is usually 0x00 for uncompressed messages. Remove the first five bytes and paste or upload the remainder.

gRPC-Web responses use a slightly different framing that includes trailers after the data frame. If you are decoding a gRPC-Web response, extract only the data body (after the 5-byte prefix and before the trailer frame that starts with 0x80). This decoder handles the protobuf layer; framing removal is a one-time manual step that prepares the input correctly.

Common gRPC debugging scenarios this tool supports

The most frequent use case is verifying that a response matches the expected schema after an API change. When a gRPC service updates its .proto definitions, downstream clients may receive unexpected field additions, type changes, or missing values. Decoding the raw response and comparing it against the updated schema catches these issues faster than waiting for a client-side deserialization error.

Another common scenario is support escalation. When a backend team needs to verify what a client received, attaching the decoded JSON to a ticket is far more readable than a Base64 blob. This tool lets support engineers or QA decode the captured payload without needing the full development environment set up on their machine.

Do I need to remove the gRPC frame header before decoding?

Yes. gRPC frames include a 5-byte prefix (compression flag + 4-byte length). Strip those bytes first, then decode the remaining protobuf payload in Binary or Base64 mode.

Can I decode gRPC-Web responses with this tool?

Yes. Extract the data frame body (after the 5-byte prefix and before the trailer frame) and decode it here using the matching .proto message type.

What if I do not have the .proto file for the gRPC service?

Without the schema, the decoder cannot map field numbers to names. You can try decoding as raw protobuf to see field numbers and wire types, but named fields require the .proto definition.

Can this tool call a gRPC endpoint directly?

No. This is a client-side decoder, not a gRPC client. Use grpcurl or a gRPC GUI client to make the call, then paste the captured response here for inspection.

How do I get the response body from browser DevTools?

For gRPC-Web, open the Network tab, select the request, and copy the response body. It is usually Base64-encoded. Paste it here in Base64 mode after stripping the frame prefix.