grpcui: Postman instincts for gRPC APIs

grpcurl with a browser instead of a terminal

grpcui is a command-line tool that lets you interact with gRPC servers via a browser, and the README's own analogy is exact: sort of like Postman, but for gRPC APIs instead of REST. Its relationship to grpcurl is stated as lineage rather than coincidence, an extension of the same organization's CLI tool, where grpcurl is the command-line interface and grpcui provides the web GUI for interactively constructing requests. The tool also browses the schema of gRPC services, presented as a list of available endpoints, so discovery and invocation live in one page. Running it prints a URL, and pointing any browser there yields the working environment, which makes it usable on machines where installing a desktop client is not an option.

Reflection, proto sources or protosets

Schema discovery has three documented paths. The seamless one is server reflection, querying a server that implements the gRPC reflection service. When that is absent, grpcui reads proto source files directly, or loads protoset files, which contain compiled file descriptor protos produced by protoc. The schema is not just documentation here: it is the machinery that transforms JSON request data into binary encoded protobuf, the same descriptors driving both the display and the encoding. The practical consequence for a locked-down service is stated plainly, if the server does not support reflection you must bring the proto sources or protosets, or there is nothing for the form to be built from. Teams that disable reflection for surface-area reasons should therefore budget for keeping protosets current.

Streaming works, all at once

Feature coverage includes all kinds of RPC methods, streaming included, and the limitation is documented with equal clarity: grpcui requires you to construct the entire stream of request messages all at once, and renders the entire resulting stream of response messages all at once. You cannot interact with bidirectional streams the way grpcurl can, because a web form is a submit-once artifact and a terminal is not. For unary calls and simple streaming this costs nothing, but for genuinely interactive bidirectional protocols the CLI sibling remains the right tool, a boundary the README draws itself rather than leaving users to discover it in confusion. Connection flexibility is broad on the other axis, with plain-text and TLS servers supported, numerous TLS configuration options, and mutual TLS where the client must present a certificate.

A form that actually understands protobuf

The request form is constructed dynamically from the selected method's message structure, and its design takes protobuf's type system seriously. Fields render as a table with three columns: name and type; cardinality, where optional fields get a presence checkbox, repeated fields get green plus and red x buttons for adding and removing values, and required fields, proto2 only, show an asterisk; and the value, showing the default when the field is absent. Rich support covers well-known types such as google.protobuf.Timestamp, oneofs and maps, the constructs that defeat naive form generators. Two alternatives to clicking: a second tab exposes the raw JSON value for editing, useful for pasting a large request wholesale, and request metadata can be set alongside the message body. Responses display all gRPC metadata, both headers and trailers, plus a human-comprehensible body as an HTML table, with the response tab disabled until you press Invoke.

brew, go install, or go run, plus one port flag

Three installation routes cover the usual audiences. Homebrew on macOS or Linux:

brew install grpcui

From source with the Go toolchain:

go install github.com/fullstorydev/grpcui/cmd/grpcui@latest

The binary lands in the bin subfolder of $GOPATH, and a repository checkout outside the module path can build and install with make install, with make updatedeps available if compile errors point at stale dependencies. Running without installing at all is also documented:

go run ./cmd/grpcui/grpcui.go -plaintext localhost:9019

Most flags control the connection to the target server, and exactly one controls grpcui itself: -port for the HTTP server exposing the UI, defaulting to an ephemeral port allocated by the operating system, so a different URL each run unless you pin it.

A scratch container and two embeddable packages

The Dockerfile is a study in minimal images: a golang:1.25-alpine builder stage compiles a completely static binary with CGO disabled and the version stamped from a VERSION file, and the final stage is FROM scratch, containing only the CA certificates, /etc/passwd, the binary, and a non-privileged grpcui user, exposing port 8080 with an entrypoint that binds all interfaces and disables browser auto-opening. The same functionality is available to Go developers as two library packages. github.com/fullstorydev/grpcui holds the building blocks for embedding a gRPC web form into any Go HTTP server, the HTML form, the JavaScript that powers it and sample CSS. The standalone package goes further, one HTTP handler supplying the entire UI exactly as the CLI presents it, bundling jQuery, jQuery-UI and the remaining assets, so a service can expose its own debugging page on an internal route.

Pinned toolchains and a steady release rhythm

Engineering hygiene shows in the Makefile. The CI target chains deps, gofmt checking, generated-code checking, vet, staticcheck, ineffassign, predeclared and tests, and a comment explains why golint and errcheck are absent, too noisy to require, with the intent to run them only against new violations. Code generation pins protoc at 22.0 and pins the protoc-gen-go, protoc-gen-go-grpc and protoc-gen-gosrcinfo plugins to exact revisions, so regeneration is reproducible, and a checkgenerate target fails the build if committed code drifts from what generation produces. Releases flow through goreleaser at a pinned version, with v1.5.2 on 2026-07-06, v1.5.3 on 2026-08-31 and v1.5.4 on 2026-09-02, and the last push on 2026-09-14. CI itself runs on CircleCI with a Go Report Card alongside, and the module builds on grpcurl, protoreflect and gRPC proper, its dependencies stating its heritage better than prose could.

Editorial conclusion

Use grpcui when you debug or explore a gRPC service and want point-and-click request construction with full protobuf typing, rather than composing JSON against grpcurl in a terminal. Use grpcurl itself when you need bidirectional streaming interaction or scriptability, since the web UI's all-at-once streaming model cannot replace it. Verify first whether your server supports reflection, and if it does not, locate the proto sources or build protosets with protoc before starting, and pin the -port flag if you want a stable URL across runs.

Frequently asked questions

Official sources

1. fullstorydev/grpcui on GitHub
2. Issues
3. License: MIT
4. README
5. Releases