superuser@gmail.com

Google

warren@kumari.net

Google

varomodt@gmail.com

ART dispatch MIME Protobuf media type application This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data.

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 .

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 () 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.

Table of Contents

• .  Introduction
• .  Key Words
• .  Payload Description
• .  Encoding Considerations
• .  Versions
• .  Security Considerations
• .  IANA Considerations
  • .  Media Type: application/protobuf
  • .  Media Type: application/protobuf+json
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

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 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 (which is optimized for wire efficiency) and the format in (which maps the Protobuf schema onto a JSON structure). Serialized objects are occasionally transported within media that make use of media types (see ) 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 .

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 when, and only when, they appear in all capitals, as shown here.

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" }

Encoding Considerations Protobuf supports the formats in and for interchange, both of which are platform-independent. For binary forms that need to transit non-binary transports, a base64 encoding (e.g., ) 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 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.

Versions was the first public version of the Protobuf schema language; , , and came later, with 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 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.

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., ). 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 ), and a manual well-formedness check may be necessary. Further, handling Unicode text generally can be quite complex (due to the problems discussed in and , 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 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 . Per , pure JSON content is indicated by a +json subtype suffix (see also ); 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 , 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.

IANA Considerations As per the process defined in , 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.

Media Type: application/protobuf

Type name:

application

Subtype name:

protobuf

Required parameters:

N/A

Optional parameters:

encoding

Indicates the type of Protobuf encoding and is "binary" by default for application/protobuf, indicating the format in . At the time of writing, no other encoding can be used for application/protobuf, so this parameter is for extensibility.

version

Indicates 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 parameter is for extensibility. Unversioned wire encodings should be treated as having version 1.

Encoding considerations:

binary

Security considerations:

See of RFC 9996.

Interoperability considerations:

The Protobuf specification includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties.

Published specification:

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, application/x-protobuffer

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:

<rmsj@google.com>, Protobuf Team <protobuf-team@google.com>

Change controller:

IETF

Media Type: application/protobuf+json

Type name:

application

Subtype name:

protobuf+json

Required parameters:

charset, which must be set to utf-8 (case-insensitive)

Optional parameters:

encoding

Indicates the type of Protobuf encoding and is json by default for application/protobuf+json, indicating the format in . At the time of writing, no other encoding can be used for application/protobuf+json, so this parameter is for extensibility.

version

Indicates 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 parameter is for extensibility. Unversioned wire encodings should be treated as having version 1.

Encoding considerations:

Same as encoding considerations of application/json as specified in .

Security considerations:

See of RFC 9996.

Interoperability considerations:

The Protobuf specification includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties.

Published specification:

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:

<rmsj@google.com>, Protobuf Team <protobuf-team@google.com>

Change controller:

IETF

References Normative References Google, LLC This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Informative References commit 97921a5 Google, LLC Chromium Google, LLC Google, LLC WHATWG WHATWG Living Standard Commit snapshot: . Google, LLC Google, LLC Google, LLC Google, LLC Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. This document discusses subsets of the Unicode character repertoire for use in protocols and data formats and specifies three subsets recommended for use in IETF specifications.

Acknowledgments provided valuable feedback to this work.

Authors' Addresses

superuser@gmail.com

Google

warren@kumari.net

Google

varomodt@gmail.com