cloudparts

MCAP

An open container file format for robot logs: many channels of timestamped, already-serialized messages in one append-only file, with their schemas embedded and an optional index for fast seeking.

What it is
File formats (binary serialization)
Used for
Logs
Type
Open source
Made by
Foxglove Technologies Inc.
License
MIT
Facts checked
13 October 2026
Website Source code

What it is

MCAP (pronounced “em-cap”) doesn’t encode messages itself. It stores messages that were already serialized in another format, such as ROS 1, ROS 2 (CDR), Protocol Buffers, FlatBuffers, Cap’n Proto, CBOR, MessagePack or JSON, and records which encoding and schema each channel uses. A file is a run of records, each a one-byte opcode, a length and the content, between magic bytes at the start and the end. Schema records hold the message definitions, Channel records name a topic and point at a schema, and Message records carry a channel ID, log and publish timestamps and the raw bytes. Attachments (calibration data, core dumps) and metadata records can ride along in the same file.

Writers append and never seek backwards, so a recorder can stream to disk or over the network, and a file cut short by a crash or power loss can still be recovered. Messages are usually grouped into chunks, each compressed with LZ4 or Zstandard and covered by an optional CRC32. At the end, an optional summary section repeats the schemas and channels and adds chunk indexes and statistics, so a reader can jump to one topic and time range without scanning the whole file, even over a slow remote connection. Chunking, indexing, CRCs and compression are all optional, so a writer can trade durability, size and seek speed.

Foxglove designed MCAP with feedback from the ROS Tooling Working Group and released it in 2022. It is the default storage format for ROS 2 bags since Iron Irwini, NVIDIA’s Isaac ROS 3.0 records to it, and the project ships readers and writers in C++, Go, Python, Rust, Swift and TypeScript, plus conformance tests and an mcap command-line tool.

Why teams pick it

  • Serialization-agnostic: Protobuf, ROS, CDR, FlatBuffers and JSON channels can share one file, so mixed stacks need only one log format
  • Self-contained: schemas are embedded, so a file stays readable years later without the code or workspace that produced it
  • Append-only writing with optional chunk compression (LZ4 or Zstandard) keeps recording fast and leaves partially written files recoverable
  • The optional index lets readers fetch one topic or time range from local or remote files without reading everything; the CLI can read straight from s3://, gs:// and az:// URLs

Watch out for

  • A container, not a codec: to read the payloads a tool still needs a decoder for each message encoding a file uses
  • Row-oriented: pulling one field out of a long recording means decoding every message on that channel, which costs more than reading one column of a columnar file such as Parquet
  • The index lives in the summary at the end of the file, so a recording cut off mid-write has no index: readers must scan it, or mcap recover can rewrite it into a valid file
  • ROS 2 bags recorded before Iron don’t embed their message definitions, so the mcap CLI can’t convert them directly; they need ros2 bag convert with the original workspace sourced

Alternatives

What all binary serialization have in common →Compare side by side →
Apache AvroOpen sourceA compact, row-based binary format with a JSON schema, widely used for Kafka messages and record files.CBOROpen sourceConcise Binary Object Representation: a binary format with JSON’s data model plus byte strings and tags, designed for tiny decoders and readable without a schema.

How it fits with other technologies

Convert a ROS bag, inspect it, and read one topic with the mcap CLI · bash

brew install mcap

mcap convert demo.bag demo.mcap      # ROS 1 .bag or ROS 2 .db3 to MCAP
mcap info demo.mcap                  # profile, duration, compression, channels
# compression:
#   zstd: [14/14 chunks] [124.89 MB/61.46 MB (50.79%)] [7.90 MB/s]
# channels:
#   (2) /tf  774 msgs (99.3..99.5Hz) : tf2_msgs/TFMessage [ros1msg]

# indexed read: print /tf messages as JSON lines
mcap cat demo.mcap --topics /tf --format=ndjson | head -n 1

See it in a real stack

No architecture uses MCAP yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2022–2024

Robotics teams logged data in whatever their framework offered. ROS 1 used bag files, hard to work with outside ROS; ROS 2 used a SQLite-based format that isn’t fully self-contained, so third-party tools struggled to read it; teams without ROS wrote length-delimited Protobuf or stuffed opaque bytes into formats like HDF5, then had to build readers in every language they used.

Foxglove, which builds visualization and data tools for robotics, set out to design a general-purpose, open container for this data. It worked out the specification with members of the ROS Tooling Working Group, including Emerson Knapp and Michael Orlov, and announced MCAP in beta in February 2022, with libraries in C++, Python, Go and TypeScript and a CLI that converts .bag and .db3 files.

Adoption came through ROS. Working with ROS 2 maintainers at Open Robotics and Apex AI, Foxglove helped make the rosbag2_storage_mcap plugin the rosbag2 default, so ROS 2 records MCAP from Iron Irwini on, with SQLite still supported. NVIDIA made MCAP the logging format for Isaac ROS 3.0 in 2024, and when Foxglove stopped open-sourcing its visualization app that year, it kept MCAP open, saying open formats are the only option for storing critical robotics data.

Why it’s built this way

A container, not another serialization format
Teams already used Protobuf, ROS messages, JSON and more. A container that stores pre-serialized messages with their schemas lets all of them, and several at once, share one file and one set of tools.
Append-only, row-oriented writing
Recorders run on robots that crash or lose power. Writing forward only lets data stream to disk or the network without seeking back, and makes partly written files recoverable.
Embedded schemas
ROS 2’s SQLite bags needed outside message definitions. MCAP files carry their own schemas, so they decode with no extra dependencies and stay readable as code changes.
Optional index and chunk compression
Like ROS 1 bags, MCAP supports indexed reads, so readers can pull one topic and time range quickly, even remotely; making each feature optional lets a writer pick its trade-offs.

Timeline

  1. 2022

    Foxglove announces MCAP in beta (February)

  2. 2022

    rosbag2 makes the MCAP storage plugin its default (December)

  3. 2023

    ROS 2 Iron Irwini records MCAP by default

  4. 2024

    NVIDIA Isaac ROS 3.0 adopts MCAP; Foxglove keeps MCAP open after closing Studio

Sources8 · facts checked 13 October 2026

Improve this page on GitHub