RFC 9996: Media Types for Protocol Buffers

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9996.¶

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

Protocol Buffers (also called "Protobuf") were introduced in 2008 as a free, open-source, platform-independent mechanism for transport and storage of structured data. The use of Protobuf has become increasingly common, and Protobuf implementations exist in many languages (C++, C#, Dart, Go, Java, Kotlin, Objective-C, Python, JavaScript, Ruby, Swift, and perhaps others). See [Protobuf] for more information.¶

Protobuf consists of an interface definition language (IDL), wire encoding formats, and language-specific implementations (typically involving a generated API) so that clients and servers can be easily deployed using a common schema. Protobuf supports two wire formats for interchange: the format in [Binary] (which is optimized for wire efficiency) and the format in [ProtoJSON] (which maps the Protobuf schema onto a JSON structure).¶

Serialized objects are occasionally transported within media that make use of media types (see [RFC2045]) to identify payloads. Accordingly, current and historical media types used for this purpose would benefit from registration. IANA has registered two Protobuf media types; see Section 7.¶

2. Key Words

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Payload Description

The media types defined in this document are used in the transport of serialized objects only. The IDL and object definitions, if transported, would be used with any appropriate text media type. In the three examples below, only the third (depicted in JSON) would ever 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;
   }

   ¶

2. 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"

   ¶

3. 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, both of which are platform-independent. For binary forms that need to transit non-binary transports, a base64 encoding (e.g., [RFC4648]) is recommended.¶

Both of the media types defined in this document include an optional "encoding" parameter indicating which encoding format is to be used with that particular payload. This is included for future extensibility. Valid values for this parameter are "binary" and "json", and other values MUST be treated as an error. See Section 7 for the defaults for each of the two registered media types. Using "binary" for the JSON type or "json" for the binary type MUST be treated as an error.¶

5. Versions

[Proto2] was the first public version of the Protobuf schema language; [Proto3], [Edition2023], and [Edition2024] came later, with [Edition2024] being current at the time of writing. Future editions of the IDL are expected.¶

These versions refer to evolutions of the schema of the IDL, not the wire format. Accordingly, a serialized object generated by any of these is compatible with any other. The media type registrations in Section 7 include support for versioning of the wire format, should it ever change, but do not refer to the IDL, which can evolve independently.¶

Note that there may be semantic changes implicit in the IDL version, which can affect the interpretation of otherwise compatible bits on the wire. For example, in Proto2, unknown values of an enumeration were interpreted as invalid, whereas in Proto3, they are retained.¶

Clients MUST reject payloads with an unsupported version number.¶

6. Security Considerations

The payload for these media types contains no directly executable code. While it is common for a Protobuf definition to be used as input to a code generator, which then produces something executable, that applies to the schema language, not serializations.¶

Protobuf provides no security, privacy, integrity, or compression services. Clients or servers for which this is a concern should avail themselves of solutions that provide such capabilities (e.g., [RFC8446]). Implementations should be careful when processing Protobuf like any binary format; for example, a malformed request to a Protobuf server could be crafted to allocate a very large amount of memory, potentially impacting other operations on that server.¶

Protobuf supports embedded content in string or bytes fields: In both cases, applications should ensure that the format of the content is precisely as expected. Note that UTF-8 validation of string fields is optional (see [ProtoFeatures]), and a manual well-formedness check may be necessary. Further, handling Unicode text generally can be quite complex (due to the problems discussed in [UniChars] and [RFC8264], for example), so it is best to rely on well-supported internationalization libraries whenever possible.¶

In order to safely use Protobuf serializations on the Web, it is important to ensure that they are not interpreted as another document type, such as JavaScript: We recommend base64-encoding binary Protobuf responses whenever possible to prevent parsing as active content. Servers should generally follow the advice of [RFC9205] to prevent content sniffing for all binary formats.¶

Further, when using JSON serializations, it is important that it is clear to browsers that the content is pure JSON so that they can inhibit Cross-Site Script Inclusion or side-channel attacks using techniques such as Cross-Origin Read Blocking [CORB]. Per [RFC6839], pure JSON content is indicated by a +json subtype suffix (see also [MIMESNIFF]); thus, when serializing Protobuf content to JSON, users MUST use the application/protobuf+json media type. When using JSON, charset can prevent certain encoding confusion attacks, so users should specify it for all JSON encodings.¶

In the type described in [Any], there is technically a link that was intended to be dereferenced to obtain schemas for a given type; however, this is not supported by widely used Protobuf implementations.¶

7. IANA Considerations

As per the process defined in [RFC6838], IANA has registered application/protobuf and application/protobuf+json in the "Media Types" registry. The following are deprecated aliases: application/x-protobuf, application/x-protobuffer, and application/x-protobuf+json.¶

8. References

Acknowledgments

Orie Steele provided valuable feedback to this work.¶

Authors' Addresses