What Is a CAR File in IPFS? How a DAG Becomes One File

A CAR file (Content Addressable aRchive) is a single file that holds an IPFS DAG: one or more root CIDs plus every block under them. You can back up, move, or hand over content as one archive. Each block keeps its CID, so whoever receives the file can verify it.

TL;DR:

• A CAR file packages a DAG, a root CID plus every block reachable from it, into a single portable archive file, similar in spirit to a .tar but built specifically for content-addressed data
• Structurally, a CAR is a header listing one or more root CIDs, followed by a sequence of block records, each pairing a CID with that block's raw bytes
• ipfs dag export writes a CID's entire reachable graph to a CAR file; ipfs dag import reads blocks back in and recursively pins whatever roots the file's header lists
• Because a CAR is just blocks plus their CIDs, importing one doesn't require re-trusting the source, every block can be independently hash-verified against the CID sitting right next to it, the same verification property this series' content-verification article covers
• A CAR file is exactly what the Trustless Gateway spec covered earlier in this series returns when a client requests a ?format=car response, the same archive format used for backup and migration is also what makes gateway responses independently verifiable

Updated Oct 19, 2026: rewrote the post for readability, added the export and import commands, and added how to get a CAR file's content onto AIOZ Pin.

Why Do CAR Files Exist?

Every retrieval method this series has covered works one request at a time against a live network. Bitswap trades want-have and want-block messages, and a gateway answers plain HTTP requests. That suits browsing. It is the wrong shape when you want to back up a pinset, move content between two nodes on different networks, or hand someone a whole dataset. For those jobs you need the DAG packed into one self-contained file.

What Is Inside a CAR File?

A CAR file has two parts. The header lists one or more root CIDs, which tell a reader where to start walking the graph. After the header comes a sequence of block records, and each record pairs a CID with that block's raw bytes. That is the whole CARv1 format, with no compression and no index. CARv2 wraps the same payload and can append an optional index for faster lookups.

Exporting: ipfs dag export

To turn a live CID into a CAR file, you run ipfs dag export with that CID. Kubo fetches every block reachable from the root and streams the result to standard output as a CARv1 file. Redirect that stream to a file and you have one archive holding everything under the root. For a UnixFS directory, that means every file and subdirectory block beneath it. Kubo's export takes a single root per file.

ipfs dag export <root-CID> > backup.car
ipfs dag import backup.car

Both commands are quoted from the Kubo CLI reference; we didn't run them for this post.

Importing: ipfs dag import

Going the other way, ipfs dag import reads a CAR file's blocks into your node's local blockstore. By default it also pins every root CID listed in the file's header, recursively. That is the same recursive pin this series' garbage collection article covers, triggered by an import instead of an upload. So handing someone the file is enough: their node can rebuild and pin the exact same DAG with no live link to you.

Verification Comes Free

Every block in a CAR sits next to its own CID, so you don't have to trust whoever gave you the file. You can recompute each block's hash and compare it with the CID stored beside it. Any mismatch shows up locally, through the same check this series' content-verification article describes for live retrieval. A CAR from an unknown mirror is as verifiable as one from the original uploader.

The Same Format Behind Trustless Gateway Responses

This series' content-verification article showed how to ask a gateway for a CAR response instead of a finished file, with ?format=car or the right Accept header. That response uses the same CAR format described here. The only difference is delivery: a gateway streams it over HTTP, while an export saves it to disk.

How AIOZ Pin Handles CAR Files

You don't need AIOZ Pin tooling to export a CAR file. Point ipfs dag export at a pinned CID from any IPFS node that can reach it. The file you get is a complete, verifiable copy that stays usable without our infrastructure, which makes it a simple way to back up or migrate a pinset.

Importing works differently. Our docs list two ways to pin: upload a file or directory with POST /api/pinning/, or pin an existing CID with POST /api/pinning/pinByHash. They don't list a CAR upload. To get a CAR file's content onto AIOZ Pin, import it into an IPFS node you run, then send the root CID to pinByHash. Keep that node online until the pin completes, since the blocks have to be fetched from it. The request body from the docs looks like this:

POST https://api.aiozpin.network/api/pinning/pinByHash
pinning_api_key: KEY
pinning_secret_key: SECRET

{ "hash_to_pin": "CID", "metadata": { "name": "string" } }

Next step: the AIOZ Pin pinning API reference has both endpoints with cURL, Node.js, Python, and Go examples.

Frequently Asked Questions

What is a CAR file in IPFS? A Content Addressable aRchive: one file that packs a DAG's root CIDs and every block reachable from them. It is a header of roots followed by CID-and-bytes block records.

How do you create a CAR file from a CID? ipfs dag export <CID> walks the CID's full reachable graph and writes the result as a CAR-formatted stream, which can be redirected to a file.

How do you get content back out of a CAR file? ipfs dag import <file.car> reads the blocks into local storage and recursively pins whatever root CIDs the file's header lists.

Do you have to trust whoever gave you a CAR file? No. Every block sits next to its own CID, so you can hash-verify each one on import. It is the same trustless check that applies to any live IPFS retrieval.

Is a CAR file the same thing as a gateway's CAR response? Yes. Requesting ?format=car from a Trustless Gateway returns the exact same archive format described here, delivered over HTTP instead of saved as a standalone file.

Do you need AIOZ Pin tooling to export a CAR file of content pinned there? No. ipfs dag export works on any CID reachable on the public network, including content pinned on AIOZ Pin. Any IPFS node with access to it will do.

Related Reading

• How IPFS Verifies Content Without Trusting the Gateway - the Trustless Gateway spec and CAR-response mechanism this article's format is shared with
• What Happens When You Unpin a File on IPFS: Garbage Collection Explained - the same recursive-pin behavior a CAR import triggers
• UnixFS: How IPFS Represents Files and Directories - what gets walked and packaged when exporting a directory's DAG
• How AIOZ Pin Actually Keeps Your Files Online: Replication, CIDs, and Proof-of-Storage - the persistence guarantee an independent CAR backup complements
• AIOZ Pin Wallet: How AIOZ Token Deposits Become Credit - the exact scenario a CAR export exists to protect against
• IPLD Selectors: Fetching Part of a DAG, Not All of It - requesting a slice of a DAG instead of the whole archive

References

• IPLD Specs: CAR (Content Addressable aRchive)
• Storacha Docs: Working with CAR Files