Protocol Buffers: Google's Serialization Format
/protobuf
Protocol Buffers is Google's schema-driven binary serialization format: .proto files compile into typed code via the protoc compiler. It earns its keep once more than one service, in more than one language, has to agree on a message shape without hand-writing a parser on each side. Skip it for a single small script or a config file a human edits directly, since the .proto-and-protoc step is overhead you don't need.
What are Protocol Buffers?
Protocol Buffers, also called protobuf, is Google's way of serializing structured data without tying you to one programming language or platform, designed to keep working as message definitions change. You describe a message once in a .proto schema file, run it through the protoc compiler, and get back generated source code that handles encoding and decoding. Full documentation lives at protobuf.dev.
Key Features for Data Interchange
- ✓A single .proto schema file compiles through protoc into generated source code for whichever language you're targeting, so the schema stays the one source of truth for the message shape.
- ✓Official runtimes for C++, Java, Python, Objective-C, C#, Ruby, and PHP live in this repo's own source directories, each with its own install notes.
- ✓Go, Dart, and JavaScript runtimes are maintained separately in protocolbuffers/protobuf-go, dart-lang/protobuf, and protocolbuffers/protobuf-javascript.
- ✓protoc ships as a pre-built binary per release (protoc-$VERSION-$PLATFORM.zip on the GitHub Releases page), bundled with the standard .proto files.
- ✓Bazel builds get first-class Bzlmod support on Bazel 8+ via a bazel_dep entry in MODULE.bazel, plus a legacy WORKSPACE path using http_archive and protobuf_deps().
- ✓A documented version support policy at protobuf.dev/version-support/ spells out how long each language library stays supported.
Common Use Cases for Protobuf
- •Defining a wire-format contract between services written in different languages, using one .proto file as the shared source of truth for message shape.
- •Working in a Bazel-based build, since Bazel 8+ gets first-class Bzlmod support through a simple bazel_dep entry.
- •Pulling a released, versioned protoc binary into CI rather than building the compiler yourself, using the per-release protoc-$VERSION-$PLATFORM.zip archives.
- •Tracking a documented support window for a language runtime via protobuf.dev/version-support/, instead of guessing how long a given release stays maintained.
Installing the Protobuf Compiler and Runtimes
Most users should start from a supported release rather than the main branch, since building against HEAD can break from source-incompatible or under-tested changes; even release branches can see some instability between release commits, so pin to a specific release commit if you're building from source. For the compiler itself: C++ users follow the C++ installation instructions in src/README.md, while everyone else can grab a pre-built protoc binary from the GitHub Releases page, packaged per release as protoc-$VERSION-$PLATFORM.zip alongside the standard .proto files. Older versions not on the releases page are available through the Maven repository. Pre-built binaries only exist for released versions, so if you need main-branch HEAD or you're modifying protobuf itself, build protoc from source per src/README.md instead. Runtime installation is per language: C++, Java, Python, Objective-C, C#, Ruby, and PHP each have their own instructions in their source directory in this repo, while Go, Dart, and JavaScript runtimes are installed from their own separate repositories. Bazel users can pull protobuf in via Bzlmod with a bazel_dep entry in MODULE.bazel, or the legacy WORKSPACE file with http_archive and a protobuf_deps() call.
Getting Started with Protobuf
The README doesn't walk through an actual .proto file or a protoc command inline. It points you to the tutorials in the developer guide at protobuf.dev/getting-started as the intended starting point, plus a set of code examples in the repo's examples directory. From there, the complete documentation lives at protobuf.dev, the version support policy is at protobuf.dev/version-support/, and there's a Google Group you can join to follow upcoming changes and connect with other protobuf developers and users.
Strengths
- ✓Official runtimes for C++, Java, Python, Objective-C, C#, Ruby, and PHP live directly in this repo, each with install notes in that language's own source directory.
- ✓protoc is distributed as a ready-to-use binary per release, so most non-C++ users never need to build the compiler themselves.
- ✓First-class Bazel support via Bzlmod on Bazel 8+, plus a legacy WORKSPACE path, for teams that are already on a Bazel build.
- ✓A documented version support policy at protobuf.dev/version-support/ tells you upfront how long a given language library stays supported.
- ✓Backed by Google, with an active Google Group where you can follow upcoming changes and reach other protobuf developers.
Considerations and Limitations
- △The facts available here don't state protobuf's license, so confirm the terms before pulling it into a commercial codebase.
- △Building from the main branch HEAD can break from source-incompatible or insufficiently-tested changes, per the README, and even release branches see some instability between release commits.
- △Go, Dart, and JavaScript runtimes live in separate repositories (protobuf-go, dart-lang/protobuf, protobuf-javascript) rather than this one, so a multi-language project means tracking more than one release cadence.
- △Pre-built protoc binaries only exist for released versions; using main-branch HEAD or modifying protobuf itself means building the compiler from source yourself.
- △The README doesn't include an inline .proto or protoc example, so the actual first-schema walkthrough lives outside this repo, at protobuf.dev/getting-started.
- △Bazel setup has changed release to release: the README notes that 30.x added extra load statements for rules_java and rules_python, so a pinned build script may need updates when you move versions.
Alternatives to Protocol Buffers
Frequently Asked Questions
This repo documents official runtimes for C++, Java, Python, Objective-C, C#, Ruby, and PHP, each installed from its own source directory. Go, Dart, and JavaScript runtimes are maintained in separate repositories: protocolbuffers/protobuf-go, dart-lang/protobuf, and protocolbuffers/protobuf-javascript.
Download a pre-built protoc binary for your platform from the GitHub Releases page, packaged per release as protoc-$VERSION-$PLATFORM.zip. C++ users, or anyone who needs main-branch HEAD or is modifying protobuf itself, should build protoc from source using the instructions in src/README.md instead.
The complete documentation for Protocol Buffers lives at protobuf.dev, including getting-started tutorials at protobuf.dev/getting-started and code examples in this repo's examples directory.
Protocol Buffers publishes its version support policy at protobuf.dev/version-support/, which lays out how long each language library stays supported.
Follow the C++ installation instructions in src/README.md. The README recommends this path if you need main-branch HEAD or you're modifying protobuf's own code, since pre-built binaries only cover released versions.
The problem it solves
Two services written in different languages that need to exchange structured data usually end up hand-writing parsers on each side, or falling back to JSON and trusting that both ends agree on field names and types as the schema drifts. Protocol Buffers turns that agreement into an artifact: you write the message shape once in a .proto file, run protoc, and every language gets generated code built from that same definition instead of a hand-maintained one.
Who should try it — and who should skip
Reach for Protocol Buffers when more than one service, likely in more than one language, needs to agree on a strict, versioned message shape and you're fine adding protoc to your build. Skip it for a single small script. Skip it too if you need a format a non-engineer can open in a text editor and read directly, since the .proto-and-protoc workflow adds a build step a plain JSON payload doesn't need.
Related repositories
Curious whether protobuf is right for you?
Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about protobuf.