Content Identifiers (CIDs)

The unique fingerprint every IPFS file receives.

CIDv0 vs CIDv1: Choose the Right Format for Your Upload

Property	CIDv0	CIDv1
Prefix	Qm...	bafy... (dag-pb, directories & multi-chunk files), bafk... (raw, small single-block content), plus others per codec
Hash function	SHA-256 only	Multiple (SHA-256, Blake2b, etc.)
Encoding	Base58 (mixed case)	Multibase — base32 by default (lowercase, DNS-safe)
Self-describing	No	Yes (includes codec + hash info)
Chunker	256 KiB legacy default	1 MiB per IPIP-0499
Leaf encoding	Wrapped in dag-pb	Raw bytes (raw-leaves=true)

What IPFS.NINJA emits

Uploads and pins made after 2026-07-13 return CIDv1 by default: CIDv1 base32 encoding, 1 MiB chunks, raw leaves — the IPIP-0499 unixfs-v1-2025 profile. Practical implications:

• Small files (≤ 1 MiB) come back as bafk... (raw single-block CIDv1)
• Larger files and directories come back as bafy... (dag-pb CIDv1)
• A file uploaded through us gets the same CID any modern tool (Helia, latest Kubo, ipfs-car) would compute from the same bytes

Backward compatibility

Legacy Qm... CIDs from earlier uploads remain fully resolvable — the gateway, POST /pin, GET /file/:cid, IPNS resolvers, and every other endpoint accept both formats indefinitely. If you have a Qm... CID from an earlier upload, nothing you built stops working.

What is a CID?

A Content Identifier (CID) is a self-describing label that uniquely identifies a piece of data on IPFS. It's derived from the cryptographic hash of the file's content, combined with metadata about the hashing algorithm and encoding format used.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

CIDs that start with bafy (or bafk for small single-block content) use CIDv1, the modern self-describing format. Legacy CIDs that start with Qm use CIDv0 (base58-encoded SHA-256) — still valid, still resolvable, but no longer the default output for new content.

Key properties

• Deterministic — The same file always produces the same CID. Upload the same image twice and you get the same identifier.
• Unique — Even a one-byte change produces a completely different CID. This makes CIDs tamper-evident.
• Self-verifying — Anyone who receives a file can recompute the hash and confirm it matches the CID they requested.
• Immutable — A CID always points to the same content. You can't change what a CID resolves to.

CIDs in IPFS.NINJA

Every file you upload returns a CID in the API response. Use it to:

• Access the file via gateway: ipfs.ninja/ipfs/<CID>
• Retrieve file metadata: GET /file/<CID>
• Reference content on-chain (NFTs, smart contracts)
• Share with anyone — they can verify the content matches

See the IPFS.NINJA overview for how CIDs fit into the upload workflow. Learn how to pin content by CID to keep it permanently accessible.