RFC 9996

Media Types for Protocol Buffers

📅 published July 2026, from ietf

Media Types for Protocol Buffers 🎀

okay bestie, this one is RFC 9996 and it's all about registering media types for Protocol Buffers (Protobuf) 💖 It's Informational (not a Standards Track spec), it's ISSN 2070-1721, and it's dated July 2026 🌸 The authors are M. Kucherawy (Ed.), W. Kumari, and R. Sloan from Google 🫶 The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract ✨

this doc registers media types for Protobuf, which is a super common, extensible way to serialize structured data 🦋

Status of This Memo 📜

this is not an Internet Standards Track spec, it's just published for info purposes 💅 It's still an IETF product that has consensus from the IETF community, got public review, and was approved by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🙈

For the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9996 ✨

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully because they spell out your rights and restrictions 🧐 Code Components pulled out of this doc have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🌈

Table of Contents 🍓

1.  Introduction
2.  Key Words
3.  Payload Description
4.  Encoding Considerations
5.  Versions
6.  Security Considerations
7.  IANA Considerations
  7.1.  Media Type: application/protobuf
  7.2.  Media Type: application/protobuf+json
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

okay so Protobuf (also called "Protobuf") launched in 2008 as a free, open-source, platform-independent way to transport and store structured data 🧚 It's gotten super popular, and there are implementations in tons of languages: C++, C#, Dart, Go, Java, Kotlin, Objective-C, Python, JavaScript, Ruby, Swift, and probably more 💅 See [Protobuf] for more info.

Protobuf is made up of an interface definition language (IDL), wire encoding formats, and language-specific implementations (usually with a generated API). That's what lets clients and servers get deployed easily around one shared schema 🔥 Protobuf supports two wire formats for interchange: the one in [Binary], which is optimized for wire efficiency, and the one in [ProtoJSON], which maps the Protobuf schema onto a JSON structure 🦋

Serialized objects sometimes travel inside media that use media types (see [RFC2045]) to label their payloads. So current and historical media types used for this purpose would really benefit from being registered 🫶 The IANA has registered two Protobuf media types, and you can find them in Section 7 💖

2. Key Words 🔑

okay so the BCP 14 key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 👑 They're interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when, and only when, they show up in all capitals like that in this doc 🙈

3. Payload Description 🧚

the media types in this doc are only for transporting serialized objects 💜 If you transport the IDL and object definitions, they'd go with any appropriate text media type. Here are the three examples, and only the third one (the JSON one) would ever actually be used with these media types ✨

  1. An example of using the IDL to specify a "Person" object:
edition = "2023";

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
}
  1. An example of python code that uses code generated from the IDL definition above to create an instance of a "Person" object:
person = Person()
person.id = 1234
person.name = "John Doe"
person.email = "jdoe@example.com"
  1. An example of the above instance expressed in JSON:
{
  "name": "John Doe",
  "id": 1234,
  "email": "jdoe@example.com"
}

4. Encoding Considerations 🌸

Protobuf supports the formats in [Binary] and [ProtoJSON] for interchange, and both are platform-independent 🎀 If you've got binary forms that need to ride over non-binary transports, a base64 encoding (e.g., [RFC4648]) is recommended 💖

Both media types here have an optional "encoding" parameter that says which encoding format a payload uses 🔮 It's there for future extensibility. The valid values are "binary" and "json", and any other value MUST be treated as an error 😭 Check Section 7 for the defaults of each of the two registered types. Using "binary" with the JSON type, or "json" with the binary type, MUST be treated as an error too 💀

5. Versions 🦋

so [Proto2] was the first public version of the Protobuf schema language 🍓 Then came [Proto3], [Edition2023], and [Edition2024], and [Edition2024] is the current one as of writing ✨ More editions of the IDL are expected later 👑

These versions are about how the schema of the IDL evolves, not the wire format 🫶 So a serialized object generated by any of them is compatible with any other. The media type registrations in Section 7 do support versioning of the wire format, in case it ever changes, but they don't refer to the IDL, which can evolve on its own timeline 🌈

Heads up though: there may be semantic changes tied to the IDL version that change how otherwise compatible bits on the wire get interpreted 👀 For example, in Proto2, unknown enumeration values were treated as invalid, but in Proto3 they're retained 💅

Clients MUST reject payloads with an unsupported version number 🚫

— part 1 of 2 — 🎀

7.2. Media Type: application/protobuf+json ✨

okay so this one is the JSON-flavoured sibling 🎀 Here's the registration template, and I've kept every field and value exactly as written:

  • Type name: application
  • Subtype name: protobuf+json
  • Required parameters: charset, which must be set to utf-8 (case-insensitive)
  • Optional parameters:
    • encoding: tells you which type of Protobuf encoding is in use. For application/protobuf+json it's json by default, meaning the format in [ProtoJSON]. At the time of writing, no other encoding can be used for application/protobuf+json, so this parameter is basically there for extensibility 🌈
    • version: tells you the version of the wire encoding specification (not the schema language), with a default of 1. At the time of writing, no protobuf wire encodings are versioned, so this one is also for extensibility. Unversioned wire encodings should be treated as having version 1 💅
  • Encoding considerations: Same as encoding considerations of application/json as specified in [RFC8259], Section 11.
  • Security considerations: See Section 6 of RFC 9996. 🔒
  • Interoperability considerations: The Protobuf specification [Protobuf] includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties. 🫶
  • Published specification: [Protobuf]
  • Applications that use this media type: Any application with a need to exchange or store structured objects across platforms or implementations.
  • Fragment identifier considerations: N/A
  • Additional information:
    • Deprecated alias names for this type: application/x-protobuf+json
    • Magic number(s): N/A
    • File extension(s): N/A
    • Macintosh file type code(s): N/A
  • Person & email address to contact for further information: Protobuf Team <protobuf-team@google.com>
  • Intended usage: COMMON
  • Restrictions on usage: N/A
  • Author: Rob Sloan <rmsj@google.com>, Protobuf Team <protobuf-team@google.com>
  • Change controller: IETF

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgments 🌸

Orie Steele provided valuable feedback to this work. Huge thanks, bestie 🧚

Authors' Addresses 💌

  • Murray S. Kucherawy (editor)
    • Email: superuser@gmail.com
  • Warren Kumari, Google
    • Email: warren@kumari.net
  • Rob Sloan, Google
    • Email: varomodt@gmail.com
📦 where this page comes from