256t.org is a public specification for content-addressable storage using 94-character content identifiers (CIDs). It defines a simple, standardized way to identify and retrieve content based on its cryptographic hash and length.
256t.org provides a simple, predictable format with fixed-length identifiers (94 characters or less) that are easy to work with in URLs, filenames, and databases. The specification is intentionally minimal and focused, making it straightforward to implement in any programming language.
While IPFS and similar systems are complete distributed storage networks, 256t.org is just a specification for content identifiers. It defines how to compute and verify CIDs, but leaves storage, retrieval, and discovery mechanisms as implementation details. This makes it simpler and more flexible for different use cases.
A CID (Content Identifier) is a 94-character or less base64url-encoded string that uniquely identifies content. It consists of: - 8 characters: length of content (base64url encoded) - Up to 86 characters: SHA-512 hash (for content > 64 bytes) OR the content itself (for content ≤ 64 bytes)
The length was chosen to fit comfortably within URL path segments and common database field sizes: - 8 characters for length (can represent up to 256 terabytes) - 86 characters for SHA-512 hash or inline content - Total: 94 characters
Base64url is a variant of Base64 encoding that uses URL and filename safe characters (defined in RFC 4648 section 5). It replaces + with - and / with _, and omits padding characters (=).
For content 64 bytes or smaller, the base64url-encoded content itself is shorter than or equal to the SHA-512 hash. Storing it inline is more efficient and avoids unnecessary hashing.
See the implementations directory for code examples in 40+ languages.
Yes! The specification is open and free to use. You can implement CID generation and verification in your application, or use one of the existing implementations.
You can store CIDs anywhere: - In a traditional database - On a filesystem (as filenames or in a dedicated directory) - In cloud storage (S3, R2, etc.) - On a CDN - In a distributed system
The specification doesn't dictate storage mechanisms.
That depends on your storage implementation. The specification defines the CID format but not the retrieval mechanism. Common approaches include: - HTTP servers with CID-based routing - Direct file system access - Cloud storage APIs - Custom protocols
The main 256t.org domain hosts a small demonstration set of CIDs, but it's not intended as a general-purpose public storage service. The focus is on the specification itself.
SHA-512 collisions are cryptographically infeasible with current technology. For content > 64 bytes, CIDs are as collision-resistant as SHA-512 itself. For content ≤ 64 bytes, CIDs are unique by definition since they contain the actual content.
While theoretically possible, engineering a SHA-512 collision is far beyond current computational capabilities. It's easier for an attacker to simply lie about content than to create a collision. Always verify CID content if security is critical.
Use any of the implementations to compute the CID of your content and compare it to the expected CID. All implementations provide verification functions.
Yes, in practice. Since a CID is derived from the content itself, the same CID will always represent the same content. If content changes, its CID changes too.
Yes. Since CIDs are content-addressed and immutable, they can be cached forever with Cache-Control: public, max-age=31536000, immutable headers.
Choose the implementation that matches your project's primary language. All implementations follow the same specification and produce identical CIDs for the same content.
Each implementation should include:
- A core library for CID computation (cid.*)
- A script to generate CIDs for example files (generate.*)
- A script to verify CIDs match their content (check.*)
See existing implementations in the implementations directory for examples.
Yes. The repository includes example files in the examples/ directory and expected CIDs in cids.json. Implementations are tested by generating CIDs for these files and verifying they match the expected values.
SHA-512 provides a higher collision resistance and the additional length (64 bytes vs 32 bytes) doesn't significantly impact the total CID size thanks to inline storage for small content.
Content of exactly 64 bytes can be stored inline (base64url encodes to ≤ 86 characters) or hashed. The specification allows both, though inline storage is preferred for efficiency.
8 characters of base64url encoding provides 48 bits of length information, supporting content up to 256 terabytes. This is sufficient for virtually all use cases while keeping the prefix compact.
Yes! For content ≤ 64 bytes, the CID is shorter because it only includes the length prefix plus the base64url-encoded content itself (which is ≤ 86 characters).
See Publishing and Storage for detailed information about deploying content-addressed storage using CIDs, including examples of uploading to Cloudflare R2.
The specification focuses on content identifiers, not metadata. However, best practices include:
- Cache-Control: public, max-age=31536000, immutable for maximum caching
- Content-Type headers appropriate to the content
- Optional: Store the CID in response headers or metadata for verification
Yes, but GitHub Pages has file size limitations and isn't optimized for content-addressable storage. For production use, consider dedicated storage services like S3, R2, or similar.
Contributions are welcome! You can: - Add implementations in new programming languages - Improve existing implementations - Report issues or suggest improvements to the specification - Improve documentation
See the GitHub repository to get started.
Open an issue on the GitHub repository or start a discussion in the GitHub Discussions section.