MessagePack MIME Type

Learn what application/msgpack represents, why application/vnd.msgpack is the registered media type, and how to inspect and convert MessagePack data.

MIME type details for application/msgpack

In active use
MIME typeapplication/msgpack
Extensions
Alternate versions
application/vnd.msgpackapplication/x-msgpack
First standardized2008
Created bySadayuki Furuhashi
Browser supportNo native browser support
Example applicationsFluentd, Redis
Poly supportPartial. Poly recognizes application/msgpack as a MIME identifier and stores the file, but it does not parse MessagePack payloads or infer this type from a filename extension.
Indexed by PolyPartial. MessagePack files are searchable by filename and basic file properties only; their serialized contents are not indexed.
Preview in PolyNo. Poly has no MessagePack viewer or text preview, so download the file to inspect it with a decoder.
Poly agentNo. The Poly agent cannot read or reason about the serialized contents of a MessagePack file.

What does application/msgpack mean?

application/msgpack is used in some software for data serialized with MessagePack, a compact binary object format. MessagePack represents familiar values such as null, booleans, integers, floating-point numbers, strings, byte arrays, arrays, and maps. It fills a role similar to JSON, but its wire representation is binary rather than human-readable text.1

There is an important naming wrinkle: application/msgpack is not the media type registered by IANA. The registered type is application/vnd.msgpack, added in May 2024. IANA records it as binary data with no standard file extension or magic number.2 Existing systems may still send application/msgpack or application/x-msgpack, so receivers sometimes accept more than one identifier for compatibility.

Use Content-Type: application/vnd.msgpack when designing a new protocol. Keep application/msgpack only where an existing integration requires it.

Where MessagePack came from

Sadayuki Furuhashi introduced MessagePack in 2008. His contemporary development archive documents the format in August, followed by C++ work and the 0.2 releases later that year.3 The format continued to evolve as a project-maintained specification. String and binary values were separated and extension types were added in 2013, followed by the timestamp extension in 2017.1

The IANA registration came much later. application/vnd.msgpack was registered on May 13, 2024, on behalf of Furuhashi.2 That registration standardized a media type for the existing format rather than introducing a new MessagePack encoding.

Why MessagePack has no single magic number

A MessagePack stream begins immediately with its first value. The first byte describes that value, so it changes with the data. For example, bytes from 00 through 7F encode small non-negative integers, 80 through 8F begin small maps, and 90 through 9F begin small arrays. Other byte values introduce strings, binary blobs, larger collections, floating-point numbers, and extension values.1

That design makes the encoding compact, but it means there is no fixed signature that reliably says, “this file is MessagePack.” A short sequence of arbitrary bytes can also happen to be a valid MessagePack value. Identification therefore usually depends on protocol metadata, a known application convention, or successfully decoding the complete input with the expected data model.

IANA likewise assigns no standard extension. You may encounter .msgpack, .msg, or application-specific names in practice, but an extension alone is not authoritative. Poly intentionally does not map any filename extension to application/msgpack.

How MessagePack stores data

MessagePack is self-delimiting at the value level. A decoder reads the leading format byte, learns whether a length or payload follows, and then continues recursively through arrays and maps. Small values use especially short encodings. A positive integer up to 127, for example, occupies one byte.1

The core model is schema-free, but it is not limited to JSON's value set. MessagePack has a distinct binary type, wider integer choices, and extension types. Extension identifiers 0 through 127 are available to applications, while negative identifiers are reserved for predefined types. The specification currently defines timestamp as a predefined extension.1

Knowing that bytes are valid MessagePack does not guarantee that you understand them. Application-defined extension values need an agreement outside the core format, and a decoder may return unknown extensions as opaque data.

How to open and inspect MessagePack data

Web browsers do not render MessagePack responses as documents. Save the response or file, then use a decoder for the language or system that produced it. The MessagePack project lists implementations for many programming environments, and its examples show the same encoded values being exchanged among languages.4

For a quick inspection workflow:

  1. Confirm the expected media type and application protocol.
  2. Decode with a maintained MessagePack library.
  3. Enable support for any extension types the producer uses.
  4. Print or export the decoded value as JSON when it contains JSON-compatible data.

Fluentd is one real-world example. Its HTTP input recognizes application/msgpack, and its formatter can emit events as MessagePack binary.5 Redis also exposes MessagePack packing and unpacking through the cmsgpack library in Lua scripts.6

Support in Poly

Poly recognizes application/msgpack as a distinct MIME identifier, so a file already labeled with it keeps that type. Support stops at identification and ordinary file management:

  • Poly does not infer MessagePack from a filename because the type has no extension mapping.
  • The indexing pipeline classifies it as an unknown media category and does not decode its values.
  • There is no in-app preview or MessagePack-specific metadata extraction.
  • Search covers the filename and ordinary file properties, not keys, strings, or other serialized values.
  • The Poly agent and poly file read cannot read the payload.

Download the file and decode it externally when you need to inspect or transform its contents.

Converting MessagePack to JSON

JSON is often the most convenient inspection and interchange target. Decode the MessagePack value first, then serialize the resulting object as JSON. Do not treat the original bytes as text or merely rename the file.

Some values need a conversion policy:

MessagePack valueJSON consideration
BinaryEncode as Base64, a byte array, or an application-defined string
64-bit integerSome JSON consumers cannot preserve it exactly as a JavaScript number
Map with non-string keysConvert keys to strings or use an array of key-value pairs
Extension valueDecode with its registered application handler or retain it as tagged opaque data
Timestamp extensionConvert to a documented date-time string or numeric epoch representation

The MessagePack specification defines ranges larger than some JSON runtimes safely represent and permits maps whose keys are not strings.1 A round trip through JSON can therefore lose type information unless the conversion introduces explicit tags.

Security and interoperability

MessagePack does not provide encryption, authentication, or integrity protection. IANA recommends supplying those properties through the application or transport layer.2 Treat untrusted payloads like any other nested binary input:

  • Set limits on byte length, nesting depth, collection size, and allocation.
  • Reject trailing or malformed data when the surrounding protocol expects exactly one value.
  • Allow only the extension types your application understands.
  • Avoid automatically constructing arbitrary language objects from decoded values.
  • Authenticate data before acting on commands or identifiers it contains.

The media type is not a schema. Two valid MessagePack payloads can use incompatible field names, numeric conventions, and extension meanings. Document that application-level contract separately, including whether the stream contains one value or a sequence of values.

Is application/msgpack the same as application/vnd.msgpack?

They are commonly intended to identify the same core encoding, but only application/vnd.msgpack is registered with IANA.2 The bytes do not change simply because an HTTP header changes. For a migration, let consumers accept both identifiers temporarily, then have producers send the registered type.

Footnotes

  1. MessagePack Project. MessagePack Specification. 2 3 4 5 6
  2. Internet Assigned Numbers Authority. application/vnd.msgpack Media Type Registration. 2 3 4
  3. Furuhashi, Sadayuki. 2008 MessagePack Development Archive.
  4. MessagePack Project. MessagePack Implementations and Examples.
  5. Fluentd. HTTP Input Plugin and MessagePack Formatter.
  6. Redis. Lua API: cmsgpack Library.
© Poly Corp. 2026