# msgpack-c: MessagePack serialization for C and C++

> msgpack-c splits into separate C and C++ libraries, both under the Boost Software License. It is a good fit when wire size matters and JSON is too fat, but the README is thin and the real documentation lives on the wiki.

**msgpack/msgpack-c** — MessagePack implementation for C and C++ / msgpack.org[C/C++]

- Repository: https://github.com/msgpack/msgpack-c
- Stars: 3,352 · Forks: 940
- Language: Unknown
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/msgpack-msgpack-c

## What msgpack-c is for, and who should reach for it

MessagePack is a binary serialization format. The README describes it as being like JSON but smaller and faster, and gives the encoding rule that makes that true: small integers fit in a single byte, and short strings need only one extra byte beyond the string itself. That is the whole pitch. If you are moving structured records between a C or C++ process and something written in another language, and JSON's text encoding is costing you bytes or parse time, this is the library that implements the format on the C side of that boundary.

The audience is narrow and specific. This is a C and C++ library, so it belongs in native services, embedded work, game servers, and protocol layers where you already control the build. It is not a general-purpose data tool. There is no command line interface here, no schema file, and no server. The README points at the wiki for the tutorial, which tells you something about the project's priorities: the code is the product, the prose is an afterthought.

## Two libraries in one repository: c_master and cpp_master

The most important structural fact about msgpack-c is that it is not one library. The README sends you to a c_master branch for the C library and a cpp_master branch for the C++ library. The releases confirm the split: the recent tags are cpp-9.0.0 for C++ and c-7.0.2 and c-7.0.1 for C, versioned independently. So the C API and the C++ API do not move in lockstep, and a bug fixed in one branch is not automatically a fix in the other.

That design has a real cost. If you have a mixed codebase, you are tracking two version numbers and two changelogs. The benefit is that each side can follow its own language's conventions instead of compromising. The C++ side can use templates and value semantics; the C side can stay plain and linkable from anything. The repository keeps a single CHANGELOG.md at the top level, which is where you should look to see what changed between the tags you are considering.

## Where to get msgpack-c and how to start

The README does not carry build instructions itself. It defers to the wiki for the tutorial and additional information, and points at the branch for your language. So the first step is choosing the branch, not running a command: c_master for C, cpp_master for C++. Once you are on the right branch, the repository is a conventional C/C++ library with a build system, and you link against it as you would any other native dependency.

Because no install command or example code appears in the README or the top-level repository files, this article does not reproduce one. Read the wiki tutorial for the first program, and check the headers on the branch you checked out. What you should expect from the API is that packing writes into a buffer and unpacking reads from a pointer plus a length. There is no schema, no field names on the wire, and no version negotiation. The bytes are the contract. If the producer and consumer disagree about the shape of the data, you get a runtime failure, not a compile-time one. That is the trade-off the format makes everywhere, and msgpack-c inherits it.

## Where msgpack-c is the wrong tool

The absence of a schema is the limitation that matters most. MessagePack encodes values, not contracts. Nothing in this repository validates that the map you packed last month still has the same keys today, and nothing tells a consumer in another language what to expect. If your data crosses team boundaries or survives a deploy cycle, you are building that discipline yourself, outside the library.

The second limitation is documentation depth. The README is a pointer page: it links to the wiki, to the two branches, and to the issue tracker. It does not document error handling, buffer ownership, or the behaviour of the unpacker on malformed input. Those answers exist somewhere in the wiki or the headers, but if you are evaluating this library by reading the README alone, you will not find them. That is a real cost during evaluation, and it is worth saying plainly rather than treating the wiki as a formality.

Finally, msgpack-c is not a replacement for a database, a message queue, or a transport. It serializes. Everything around the bytes, including framing, retries, and compatibility across versions, is your problem.

## How it compares to JSON and to language-native MessagePack libraries

The obvious alternative is JSON. JSON is text, human readable, universally supported, and debuggable with your eyes. MessagePack is binary, so a captured payload is opaque without a decoder. The README's claim is that MessagePack is smaller and faster, and the encoding rule it cites explains the size half: single-byte small integers and one extra byte for short strings. The speed half depends on your parser, and the README does not quantify it. If your payloads are small and your bottleneck is elsewhere, JSON costs you nothing and saves you a decoder dependency.

The second alternative is a MessagePack library in your host language, for example the Python implementation that shows up in search results. The difference is not the format, which is the same, but the API surface and the build story. A Python library installs with a package manager and needs no compiler. msgpack-c is a native dependency you build and link, which buys you control over allocation and no interpreter in the path. Pick based on where the data is produced and consumed, not on the format, because the format is identical on both sides.

## Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-09-19, five days before this writing, so the project is being worked on. The release cadence is visible in the tags: cpp-9.0.0 and c-7.0.2 both landed on 2026-08-25, and c-7.0.1 on 2026-06-09. Major version numbers on the C++ side mean you should read CHANGELOG.md before upgrading across one, because a 9.x bump is not a patch.

The licence is the Boost Software License, Version 1.0, and the README points at LICENSE_1_0.txt for the text. The repository metadata reports the licence as NOASSERTION, which is a tooling artifact rather than a contradiction, but it is worth knowing if your compliance pipeline reads that field automatically: it may flag this dependency for manual review even though the README is unambiguous. Boost 1.0 is permissive and does not require you to open your own source, but read the actual file rather than a summary, since this is not legal advice and your organisation's policy is the thing that decides.

## Conclusion

Adopt msgpack-c if you are writing a C or C++ service that exchanges data with other MessagePack implementations and you can live with the wiki as your documentation. Do not adopt it if you need a schema registry, a CLI, or a single unified C/C++ API, because this repository provides none of those. Before committing, verify which branch matches your language, check the CHANGELOG for the release you intend to pin, and confirm the Boost Software License, Version 1.0 terms in LICENSE_1_0.txt against your distribution policy.

## FAQ

### What is MessagePack, and what does msgpack-c implement?

MessagePack is a binary serialization format that the README describes as like JSON but smaller and faster, with small integers encoded in a single byte and short strings needing one extra byte. msgpack-c is the implementation of that format for C and C++, split into a C library and a C++ library on separate branches.

### Is MessagePack faster than JSON with msgpack-c?

The README states that MessagePack is faster and smaller than JSON but gives no measurement, so the size claim is the one you can verify from the encoding rules it describes. Speed depends on your parser and payload, and the repository does not publish a benchmark.

### How do I install msgpack-c?

The README does not contain build steps. It directs you to the c_master branch for the C library and the cpp_master branch for the C++ library, and to the wiki for the tutorial and additional information, so start there before building.

### Are the C and C++ versions of msgpack-c released together?

No. The recent tags are cpp-9.0.0 for C++ and c-7.0.2 and c-7.0.1 for C, released on different dates, so the two libraries version independently.

### What licence does msgpack-c use?

The README states that msgpack-c is licensed under the Boost Software License, Version 1.0, with the text in LICENSE_1_0.txt. The repository metadata reports NOASSERTION, so automated licence scanners may ask for manual confirmation.

## Sources

- [Issues](https://github.com/msgpack/msgpack-c/issues)
- [msgpack/msgpack-c on GitHub](https://github.com/msgpack/msgpack-c)
- [README](https://github.com/msgpack/msgpack-c/blob/master/README.md)
- [Releases](https://github.com/msgpack/msgpack-c/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/msgpack-msgpack-c