Did you know? A blockchain can prove that a file matches a recorded digital fingerprint while the file itself lives on an ordinary server, a distributed storage network or somebody’s computer. The chain and the file are often separate. That distinction matters for school certificates, artwork, photographs, medical documents, contracts and almost anything described as “stored on blockchain.”
Imagine that Alicia uploads a beautiful digital painting to a classroom gallery. Tricia records a reference to it in a shared ledger. Kai Kai opens the gallery page and sees the painting. Months later, the gallery website goes offline. The ledger entry still exists, but the painting no longer loads. Did the blockchain fail? Not necessarily. The design may never have placed the full painting on the blockchain.
This article explains how blockchain technology works when information is stored, referenced, fetched and preserved. We will trace the differences between on-chain bytes, contract state, a hash, a content identifier, an NFT metadata file and the actual media. You do not need to buy a token, create a wallet or upload personal documents to understand any of it.
Quick answer: blockchains store defined protocol data and state under their rules; an application may store only a hash, URI or content identifier on-chain while keeping a large original file elsewhere. A cryptographic hash can help detect changes to a supplied file, but a hash cannot reconstruct a missing file. Content-addressed systems such as IPFS help identify and retrieve matching data when a provider makes the data available. Long-term availability requires operational retention, redundancy, verifiable backups and a plan for failure.
If you only have a minute, read “One key and three different things.” If an NFT image disappears, use the metadata and gateway sections. If you are designing long-term school records, use the evidence and retention sections. The technical foundation lives in What Is Blockchain? and the How Blockchain Works reading series. This article owns the focused question of where the file actually lives.
One key and three different things
Picture a school library. It has a catalogue entry saying “Science Atlas, shelf D12.” The catalogue is a record. The shelf address is a locator. The book is the content. If a flood destroys the book, the catalogue entry can remain perfectly legible while the original book is unavailable.
The same separation often appears in blockchain applications. A ledger record may contain a small value such as a hash or content identifier. A URI tells a reader where or how to request related information. The actual original document, image, video or dataset may be much larger and may be maintained by completely different infrastructure.
Did you notice what a catalogue entry cannot do? It cannot recreate every page of a destroyed book unless it actually contains the pages or there is an independently preserved copy. A hash is even more concise. Its purpose is identification or integrity checking under defined assumptions, not data compression that allows arbitrary reconstruction of the original.
This is why “blockchain stored my photo” needs a follow-up question. Was the full image data included in a transaction, encoded within contract code or state, or merely referenced by information that the ledger records? The answers have different cost, preservation and privacy consequences.
The library picture is only an analogy. Blockchains additionally have consensus, cryptographic commitments, protocol history and state-transition rules. Those mechanisms can strengthen confidence in a particular record. They do not automatically operate the school library’s shelves or copy a missing book into existence.
What on-chain storage can mean
The phrase on-chain can refer to several distinct technical things. A transaction may carry input data. A deployed smart contract may contain code. A contract may maintain persistent state. A block may contain records or commitments that participants verify. These are not identical storage arrangements, and their costs and retention properties vary by network.
For an Ethereum smart contract, persistent storage is a defined part of the contract’s state model, while memory is temporary to a call’s execution. Events and logs can be part of transaction receipts and are often processed by off-chain indexers. A reader should not assume that a value visible in an explorer’s “events” tab is an ordinary state variable.
Some artists and developers intentionally put full media data or a generative artwork’s rules on-chain. Others record a compact commitment to externally stored content. Both can be legitimate designs. The first may increase dependence on the network’s historical data being preserved, while the second requires separate preservation of the media.
Large files can be expensive or impractical to place directly in general-purpose replicated blockchain data. Each node’s duties, state size, bandwidth and execution limits matter. It is sensible to ask whether every participant needs the original bytes or only an independently checkable commitment.
When a seller advertises that an item is “fully on-chain,” do not treat the phrase as a uniform guarantee. Ask which bytes are included, what software can reconstruct the image, whether external libraries or fonts are required and what historical data must remain accessible. The precise answer is a design-specific claim.
Ethereum’s Smart Contract Anatomy and Decentralized Storage are useful starting points for understanding why code, state and bulk files are handled differently.
What is a cryptographic hash?
A cryptographic hash function maps specified input bytes to a fixed-size output under defined properties. If you have the bytes of a file, you can calculate the relevant hash and compare it with an expected value. If they match under the intended algorithm and correct encoding assumptions, the match is strong evidence that the supplied bytes agree with the recorded fingerprint.
But a hash is not a smaller copy of the file in the ordinary sense. Knowing the hash of a 20-megabyte painting does not let you restore the painting’s pixels if every actual copy has been lost. The information needed to reconstruct the original is not present in that short identifier.
This distinction is central to honest blockchain explanations. A ledger can anchor the hash of a certificate and help detect if someone later presents a different certificate. That does not mean the certificate was stored in the ledger, that its issuer was authorised, or that the wording on the certificate was true.
Hashing also depends on exact bytes. If a PDF is recompressed, edited, re-saved with different metadata or transformed into another format, its hash may change even if the document looks similar to a person. A verification process must specify which exact representation is being compared.
Did you know that a new hash is not automatically an error? A legitimately corrected document should normally have different bytes and therefore a different hash. The system must explain how versions relate and which version an institution currently accepts.
The NIST Secure Hash Standard describes major hash algorithms. The broader Cryptographic Guarantees and Threat Models explains why a correct mathematical check does not establish every outside claim.
What an IPFS content identifier tells you
IPFS is a system for addressing and retrieving data by content rather than relying only on a conventional location-based URL. A content identifier, often shortened to CID, is built from content-addressing information under a defined encoding and hashing arrangement. It lets software ask for data corresponding to that identifier.
The crucial distinction is that a CID describes what content is wanted, not a promise that a specific server is keeping a copy online forever. An HTTP address often identifies a location controlled by a host. A content-addressed request identifies content that a provider must still make available for retrieval.
In some IPFS workflows, a large file is divided into blocks. The blocks and their relationships contribute to the resulting content identifier. This means the CID is not necessarily just “the SHA-256 hash of the visible image file.” Details such as chunking, formatting, codecs and directory wrapping can affect what identifier is produced.
The IPFS Content Identifiers documentation explains that a CID is based on content and does not itself specify where that content is stored. Readers do not need to learn its full encoding to understand why a content-addressed record and the physical disks serving it are separate layers.
Suppose the fictional school painting has a CID. Two independent providers may serve matching content. That can increase resilience when both really retain the data. But if no reachable participant preserves the required blocks, the identifier still cannot supply the missing bytes.
Think of the CID as a powerful test for which data you want. The separate question “Who is still keeping those bytes available?” remains operationally essential.
Why adding a file to IPFS does not mean it will live forever
A computer participating in IPFS may store data temporarily, cache fetched content or protect chosen content from garbage collection. Retention depends on what that node or its operator does. Data that is not protected may be removed when space is reclaimed. The network does not magically transform every file ever mentioned into permanent storage.
Pinning is one mechanism used to keep specified content stored by a node or a pinning service. Pinning tells a configured participant to preserve the relevant content rather than treating it as disposable cache. Multiple independent providers can improve resilience if one fails, but there is no absolute guarantee that each provider will operate forever.
This is especially important when readers see a CID listed in an NFT or school-project record. A permanent-looking identifier can remain valid while the content becomes unavailable because no provider retains it. The integrity guarantee has not failed; the retention arrangement has failed.
The IPFS Persistence guide explains storage retention and garbage collection. The IPFS Pinning guide shows why content must be deliberately retained to remain fetchable.
A school could assign responsibility to its library system, an independent archive and a backup provider, then periodically check that the stored bytes match the expected identifiers. That is a more realistic preservation policy than assuming one upload button creates an eternal archive.
Even good pinning arrangements require funding, monitoring, migration plans and recovery procedures. A commitment to preserve files is a service obligation with identifiable operators, not a magical consequence of recording a hash.
A gateway is a viewing route, not necessarily the storage owner
Many people encounter IPFS through an ordinary web browser. An IPFS gateway lets an HTTP client request content associated with a CID. The gateway may retrieve and serve the material without requiring the reader to operate a full IPFS node. That makes content-addressed information accessible to more users.
But a gateway is another service with its own uptime, filters, caching and security policies. If one gateway returns an error, the content might still be available from another provider. Equally, an attractive gallery page is not proof that the underlying content is reliably preserved.
Alicia opens a CID through one gateway and sees her painting. Tricia tries a different gateway and gets a timeout. Before assuming that one of them has a forged file, the school checks network reachability, request format, provider availability and whether the actual bytes can be retrieved and verified.
A malicious or compromised gateway may serve a misleading interface, insert tracking or display additional content around a file. When integrity matters, the verifier must check the returned bytes under the correct content-addressing rules rather than trusting a page title alone.
A school should also consider whether third-party gateways are suitable for sensitive material. An otherwise private-looking reference may cause a service to log user requests. Public URLs and persistent identifiers can reveal patterns of access even when the viewer only intended to read a public catalogue.
The key vocabulary is helpful: a CID identifies the desired content, a provider stores it, and a gateway is one possible route for retrieving it. None of those words should be silently substituted for the others.
How an NFT points to an image
An NFT is a token defined by a smart contract’s rules. In an ERC-721 system, a token has an identity within the relevant contract and chain. The optional metadata extension provides a method such as tokenURI that can return a URI for information associated with that token.
The referenced metadata is often a structured document, for example JSON, containing a title, description and image URI. The image URI may lead to media on an ordinary web server, a content-addressed system or a different supported arrangement. The token and the image can therefore have different storage and availability conditions.
Imagine Tricia owns a fictional ART token representing a digital painting. The blockchain can show that the contract recognises her address as the token owner under its rules. The image may load from an external server operated by the gallery. If that server disappears, the token record does not automatically vanish—but the image might become unavailable.
Another design may place metadata or media directly on-chain. That can reduce dependence on one external hosting service, but the actual reconstruction can still rely on particular software, standards, data availability and chain continuity. The details matter more than a slogan.
ERC-721 does not universally guarantee copyright ownership, licence rights or delivery of a physical object. Those claims depend on contracts and external legal arrangements. Keeping token identity, media availability and rights distinct protects readers from confusing several layers.
The ERC-721 standard defines the optional metadata interface. It also makes clear that metadata URIs can be designed in different ways. Always inspect the particular token’s documentation and on-chain implementation before describing an image as permanent.
Why a record may survive after its webpage disappears
A blockchain explorer can show an old transaction even when the original application website no longer exists. This does not mean the website was stored in the blockchain. It means the network’s history and the independent web service were two separate infrastructures.
Take the fictional art gallery. The gallery database holds product pages, creator biographies, thumbnails, invoices and customer support information. The blockchain stores an accepted token or transaction record. Months later, the gallery operator closes its business. A network explorer may still display token identifiers and transfers while the biography, images and receipts have become inaccessible.
A well-designed preservation project anticipates that possibility. It might place key metadata under content-addressed identifiers, preserve copies through independent archives, document the rights to those copies and publish clear contact details for future custodians. The storage plan should match the importance of the records.
The chain’s history does not guarantee that a private marketplace’s accounts and invoices are recoverable. An NFT record may show which token moved; it does not reproduce every business communication that accompanied the sale. Similarly, a school certificate hash cannot recreate the student’s full academic history if the issuer loses its records.
This is a practical reason to avoid promises like “the blockchain is the backup.” The accurate statement may be “the blockchain stores an integrity anchor while the original data is backed up under a separate retention policy.”
Anyone designing a system should write that policy explicitly. If it is missing, the record’s survival and the reader’s ability to reconstruct the claimed content may diverge over time.
Worked example: an examination certificate
A fictional academy issues Tricia a science qualification. It creates a PDF certificate that includes her name, course, date and awarding authority. Instead of publishing the full PDF to a public blockchain, the academy records a carefully defined hash and an issuer-controlled reference within an appropriate verification system.
Later, a university receives a copy of Tricia’s certificate. The university can calculate the hash of the exact submitted bytes, compare the relevant record and check whether the issuer was genuinely authorised to make the claim. The chain can help detect alteration, but it cannot by itself prove the academy was properly accredited.
Now the academy changes its name. A trusted institutional record can establish continuity between the old and new names. The existing hash may remain associated with the original certificate bytes. The university needs governance evidence as well as cryptographic evidence to determine whether the qualification is still recognised.
Suppose the university loses the PDF and can find only its hash. Can the blockchain give back the original certificate? No. The hash is not a compressed copy. The issuer or another authorised custodian needs to preserve the original document or a verifiable reissued record.
The privacy issue is just as important. Publishing a student’s name, grades and identifiable records permanently on a public ledger can create serious data-protection problems. A narrower integrity anchor may avoid some unnecessary disclosure, though hashes of predictable personal information can still pose privacy risks depending on the design.
This example demonstrates how blockchains can support verification without being suitable repositories for raw personal documents. The detailed owner topic is Verifying an Education Credential.
Worked example: an art gallery’s missing image
Alicia uploads an original painting to a fictional gallery. The gallery records an NFT identifier and a metadata URI that points to a server-hosted JSON file. That JSON includes an image URL. For a few years, everything works: the token is visible, the metadata loads and visitors can see the painting.
Then the image URL returns a 404 error. The NFT contract continues to recognise its token identifier, but the web-hosted image is unavailable. An indexer might still show a cached thumbnail, making the problem less obvious. The thumbnail is useful as a reference but does not necessarily preserve the full-resolution original.
A careful investigation checks the token contract and metadata URI, retrieves the metadata if possible, checks the image URI, asks whether backups exist and identifies which party committed to retain the media. Reposting a screenshot is not a full preservation solution if the original high-quality file is unavailable.
If a content hash of the painting was recorded, a recovered copy can be checked against it. That can establish whether the recovered bytes match the earlier commitment. If no copy survives, the hash cannot recreate the missing file.
The gallery should state whether it has immutable or mutable metadata, who can change its pointers, what happens to broken links and whether token holders have permission to store independent archival copies. The word “NFT” alone answers none of those questions.
This is why a buyer reading an NFT listing should investigate the media’s actual storage arrangement instead of assuming the token and the artwork are physically the same digital object.
Worked example: a science dataset that is corrected
Kai Kai operates a fictional environmental study in which a sensor records rainfall totals. The dataset is stored off-chain, and the project anchors a hash to help reviewers detect alterations. Later, investigators discover that one sensor was miscalibrated, so they produce a corrected dataset.
The corrected file has different bytes and normally a different hash. That is not evidence of tampering by itself. The project should preserve a clear version relationship: which original data were collected, what error was discovered, how the correction was calculated and which corrected file should now be used for conclusions.
A blockchain anchor can support a timeline of versions. It cannot tell a researcher that the corrected measurements are scientifically valid without credible methodology, calibration evidence and independent review. Those are facts about the outside world that require additional sources.
The storage decision also matters. If only the corrected dataset remains available and the original was deleted, reviewers may be unable to reproduce the correction. The original hash will still exist but cannot reconstruct the original measurements. A research archive may therefore retain both versions with appropriate access controls.
On the other hand, if the dataset contains identifiable student responses or sensitive observations, permanent public availability may be inappropriate. The project needs a retention and access policy that balances scientific reproducibility with privacy and law.
The lesson is that integrity and verifiability are not substitutes for research governance. A good evidence system can show what changed, why and under whose authority without claiming that any individual file is eternally perfect.
What happens when nobody pins the file?
Suppose a student posts the CID of her artwork in a shared classroom record but does not arrange for any reliable service to retain the underlying blocks. A laptop originally serves them. The laptop is later reformatted, and another temporary cache eventually removes its copy. The CID is still a valid description of the expected content, but no reachable participant is known to hold it.
This is the difference between a persistent name and persistent availability. The identifier survives in a report, yet the file cannot be fetched. A reader can still check any future recovered copy against the CID under the appropriate representation, but cannot create a copy from the identifier alone.
A robust preservation plan should specify at least one accountable storage custodian and preferably independent redundancy appropriate to the value of the data. It should include periodic retrieval checks, not only successful upload confirmations. A system that never tests restoration may discover failures only when a reader urgently needs the file.
The plan should also record file formats and necessary decoding software. Retaining exact bytes is not enough for long-term understanding if the format or software is no longer available. For a digital artwork, fonts, scripts, shaders and related assets may be part of what needs preserving.
IPFS pinning can be a useful element of the plan. It is not the only option and not a universal guarantee. Conventional archives, institutional repositories and appropriately controlled backups may be more suitable for particular educational, medical or legal records.
The most important question is concrete: “Who has committed to keep the required bytes, and when was successful retrieval last tested?” A record that cannot answer it should not advertise assured long-term availability.
Does storing everything on-chain solve permanence?
Placing complete data on-chain can reduce dependence on an external host for those specific bytes, but it is not free from technical or institutional assumptions. The relevant network needs to continue operating, appropriate historical data must remain retrievable under its ecosystem, and clients must know how to interpret the bytes.
On-chain storage can also be costly. General-purpose execution networks meter storage and data because widespread replication and validation require resources. A design that puts enormous videos, full textbook archives or private school records into replicated state may burden the network and create privacy or compliance problems.
Some projects distinguish contract storage, transaction input data, event logs and specialised data-availability mechanisms. Those categories do not necessarily offer the same retention or retrieval guarantees. A developer should not promise permanent access merely because a byte was once broadcast somewhere in the ecosystem.
If the claim is “fully on-chain artwork,” ask whether the original image data, instructions to generate it and all required dependencies are truly included. A generative image may be reconstructed from code and parameters, but that requires the correct interpreter and assumptions about the execution environment.
If the claim is “permanent records,” ask who maintains historical nodes, archives and indexing tools. Accessibility to an ordinary student using a browser is a separate consideration from theoretical presence in an archival dataset.
The honest trade-off is that deeper on-chain storage can strengthen some forms of record availability or integrity under the chain’s security model while imposing greater cost, complexity and public exposure. Good system design evaluates those trade-offs rather than using an absolute slogan.
How to tell whether a token’s metadata can change
When reading a token record, inspect the actual contract and its metadata mechanism. An ERC-721 tokenURI can point to metadata returned by a separate service, and the contract may or may not permit authorised parties to modify the returned pointer under its design. The external server may itself change the response at a stable URL.
If metadata is pinned to a content-addressed identifier, changes to the underlying bytes normally produce another identifier under the same encoding rules. That can make silent substitution more detectable when the original expected CID is fixed and trusted. However, the contract might have a mutable pointer that can be changed to a new CID, so the overall promise still depends on contract authority.
A conventional HTTP metadata address may return new content tomorrow even if the URI string does not change. Caching can complicate what different viewers see. An application may display a thumbnail from an earlier cache while another application retrieves updated metadata.
This situation resembles an ordinary published article with revisions, except the token’s ledger identity and the media’s versioning can be governed by different systems. The correct question is not simply “Is the NFT on-chain?” It is “Which parts are fixed, which parts are mutable, and who has authority to change them?”
A trustworthy project publishes a clear metadata policy, identifies important dependencies and does not describe changeable media as immutable without qualification. A reader can then decide whether that arrangement meets the actual use case.
For the related problem of two websites displaying different information, see Why Two Block Explorers May Disagree.
Privacy: why an unchangeable hash is not always harmless
A project may decide not to put a private document on-chain and instead publish its hash. That is often less revealing than publishing the raw personal document, but it does not automatically remove all privacy concerns. If the original input comes from a small predictable set—such as a yes/no medical answer—an observer may be able to hash likely candidates and compare results.
The risk depends on what is hashed, the algorithm, whether a randomised commitment or other protective method is used, and what additional public data can be correlated. Pseudonymous address activity can sometimes be associated with people or institutions through outside information.
If a school promises to delete a student’s records, it should understand where copies, backups, caches, public references and ledger commitments exist. Simply removing a webpage may not remove all copies. Likewise, storing an encrypted file on a public network does not make privacy independent of long-term key management.
Encryption protects confidentiality under its assumptions; hashes support integrity and identification; access controls manage who can retrieve or use information; retention policies decide when copies should be deleted. Those are different jobs. None alone guarantees complete legal compliance.
A responsible design publishes only what is necessary, stores sensitive originals in suitable access-controlled systems and defines how long data should remain available. The selection should reflect applicable data-protection obligations rather than blindly maximising permanence.
For further discussion, use eduKateSG’s Blockchain Data Protection: Trace Every Copy Before Promising Deletion. The deeper principle is to evaluate data-life-cycle risk before uploading, because a public commitment can be difficult to retract.
Encryption is not the same as storage
Suppose Tricia encrypts a file before uploading it to a storage provider. The encrypted bytes may remain available, but a person without the correct decryption key cannot read the original contents under the encryption scheme’s security assumptions. The file’s availability and its confidentiality are now separate properties.
If Tricia loses the decryption key, having the encrypted file and its hash may not restore the readable original. If the key is stolen, the encrypted content may no longer be confidential even if the provider remains honest. A blockchain reference does not solve either problem automatically.
A university could therefore keep an encrypted archival copy, a separate integrity commitment and a documented process for authorised key recovery. Such a scheme requires careful governance over access, backup, revocation and retention. Blindly placing encryption keys on the same public ledger as the data would undermine the purpose.
Readers sometimes hear “encrypted on-chain” and assume both that the file will be retrievable forever and that only the intended person can read it. Neither claim follows from those two words alone. You need to examine where the ciphertext is, how it is stored, who has the key and what happens when the key or provider disappears.
Even a perfectly encrypted file may need metadata such as a format version, intended audience and integrity-checking information to remain usable. Those details should be handled without unnecessarily leaking the contents or identities involved.
The student-friendly distinction is simple: storage answers can I get the bytes? Integrity asks are these the expected bytes? Encryption asks who can understand them? Identity and authorisation ask whose claim or right does the file represent?
A practical rescue plan when a file no longer loads
First determine whether the problem is a missing file, a broken viewing route or a display problem. Check the exact URI or CID and the relevant network identity. A webpage’s failure can be caused by browser policy, gateway downtime, DNS changes, expired hosting or loss of the underlying content.
If the record supplies a CID, an authorised investigator can test whether another trusted provider can serve the required content, without exposing private materials to unknown services. If a recovered copy exists, verify its content identifier under the specified encoding method. Do not assume that a filename match proves byte-for-byte integrity.
If the metadata URI is still available but its image URI fails, record both links separately. If the token contract’s pointer has changed, ask which authority made the change and whether the original expected content was documented. A cached preview can be useful evidence of a prior appearance but does not necessarily establish a complete archival copy.
If no matching file is available, be candid. The blockchain record may be intact while the original content is missing. Reconstructing the file from a thumbnail or generating a visually similar replacement is not the same as recovering the original bytes. Label any reconstruction as such.
For organisations, an incident report should record the affected files, expected hashes or CIDs, last successful retrieval, responsible custodians, backup status, privacy constraints and the recovery decision. If students’ sensitive records are involved, do not publish their details in a public troubleshooting thread.
The aim is to separate the failure of retrieval, the failure of integrity, the failure of identity and the failure of display. That classification tells everyone what can still be proven and what must be repaired.
A classroom experiment using a paper hash
For a harmless demonstration, draw three boxes on a sheet of paper. In the first, write a short fictional story. In the second, write an invented “fingerprint” label—for example, STORY-17. In the third, write a catalogue entry saying where the story is kept. Tell classmates that STORY-17 stands in for a cryptographic hash without pretending the invented label has actual cryptographic security.
Now take away the first box and leave the fingerprint and catalogue entries. Can anyone reconstruct every exact word of the story? Not from those labels alone. The exercise helps explain why a real hash cannot be used as a magical backup of a lost large file.
Next, add two copies of the story held by independent classmates. If one copy is lost, the other can preserve availability. Introduce a rule that checks whether the two copies match the approved original. That models how redundancy and integrity checking complement each other.
Then imagine one student maintains a web link to the story. If that student closes the website, the independent copies might still exist. If neither student has retained the story, the link and fingerprint are insufficient. The class has now separated a lookup service from storage and from the record of an expected file.
Finally, ask who is allowed to publish a corrected version and how readers would know it was a correction. This connects the exercise to governance and evidence rather than treating the hash as an answer to every question.
The demonstration needs no live blockchain, personal account or financial asset. Its success lies in learning to name the different pieces of a storage system.
How an organisation should design for long-term evidence
A responsible long-term archive begins with a requirement statement: which documents need to remain readable, for how long, for whom and under what privacy rules? A programme preserving public research articles has different obligations from one storing confidential student evaluations or employee health records.
Then define the custody model. Who holds the original bytes? Which independent copies exist? How is integrity checked? Which file formats are acceptable? Who owns the retention budget, and what happens if a supplier goes out of business? What process handles corrections and withdrawals?
A blockchain may support an audit history or integrity commitment if several parties need a shared verification mechanism. But the original data’s availability usually still depends on storage operators and governance. The archive should not present the network as the sole accountable custodian when it is not.
Monitoring matters. An operator should be able to retrieve representative files, compare their hashes, report missing copies and restore content using verified sources. A periodic dashboard that says “all CIDs recorded” is insufficient if nobody can fetch the underlying files.
Accessibility matters too. Future students may need captions, alternate text, readable formats and clear instructions for locating historical versions. Preserving a binary file without usable documentation may technically retain bytes while failing educational access goals.
Finally, plan exit and migration. What happens when a storage provider, cloud account, gateway or institution closes? Can a successor take custody without breaking the verification route? Written answers make a system dependable long after a technology launch announcement is forgotten.
Nine claims about blockchain files worth correcting
“If I know the hash, I can download the file.” Only if the required bytes are available from a suitable provider or archive. A hash cannot reconstruct arbitrary missing content.
“IPFS stores every file forever.” IPFS content addressing and retrieval are not guarantees that an operator will retain every file. Pinning and accountable storage arrangements are important.
“A CID tells me which company holds the file.” It identifies the content under defined rules, not necessarily the physical storage location. Discovery and retrieval use separate mechanisms.
“All NFT images are inside Ethereum.” Many token systems point to external metadata or media. Some use fully on-chain designs, so the actual contract and URIs must be checked.
“A green badge proves the artwork is original.” An integrity or code-verification badge can establish a narrower digital fact. Original authorship, rights and real-world authenticity require other evidence.
“The token vanished when the image failed to load.” The token’s recorded state and the image host can be different systems. Inspect them separately.
“On-chain always means publicly readable forever.” Actual accessibility depends on protocol, available historical data and reconstruction tools. Different on-chain data types have distinct guarantees.
“Hashing personal data automatically makes it anonymous.” Identifiability may remain depending on the input, context and design. A hash is not a blanket privacy exemption.
“A blockchain archive removes the need for backups.” Data availability, decoding, privacy compliance and operational continuity still need independent planning.
Correcting these claims is not opposition to blockchain. It is a way to make the technology useful by assigning each component a job it can actually perform.
A file-evidence worksheet for readers
Write five headings across a page: record, identifier, actual bytes, custodian and rights. Under record, describe what the blockchain stores or commits to. Under identifier, name the hash, CID or URI and its encoding or network context. Under actual bytes, identify the file representation that must be reproduced exactly.
Under custodian, name who operates the storage, what redundancy exists and when the data was last retrieved successfully. Under rights, identify who issued the content, who may access it, how corrections are handled and what claims the file is intended to support.
Then perform a thought experiment. Suppose the original server closes. Which independent copies remain? Could a student still retrieve the data? Suppose the file is edited. How would the expected hash or version history reveal the difference? Suppose the issuer is fraudulent. Which evidence could establish that the contents were untrustworthy even though the hash matches?
The worksheet is simple enough for upper-secondary students and precise enough to surface serious architecture questions. It prevents a common error: assuming one beautiful blockchain explorer page establishes availability, integrity, authorship, legal ownership and privacy all at once.
For practical readers, the single most useful question is: if every website in this screenshot disappeared tomorrow, which verified bytes would still exist, and who would be responsible for providing them? If nobody can answer it, the preservation claim is incomplete.
Frequently asked questions
Are images stored directly on the blockchain?
Sometimes, but not always. Many applications record a token, metadata URI, hash or commitment while media lives on a web server or distributed storage network. Fully on-chain designs exist and should be evaluated under their specific data and software requirements.
Does a file hash contain the original file?
No. A cryptographic hash is a compact output derived from specified bytes. It can help check an available copy, but it cannot reconstruct an arbitrary missing file.
What is IPFS?
IPFS is a content-addressed data organisation and retrieval system. A CID identifies content under specified encoding rules. Data still needs to be stored and made reachable by participating providers.
Does an IPFS CID guarantee permanent availability?
No. A CID can remain valid even when no reachable node retains the corresponding blocks. Pinning, redundancy and a retention plan help provide availability but depend on accountable operators.
Why does an NFT still appear when its picture is missing?
The token’s contract state and the picture’s hosting may be separate. The network may recognise the token while the metadata or image URI fails. Inspect each layer independently.
Can a token’s metadata change?
Depending on the contract and external hosting design, a pointer or the content returned by a URI may be mutable. A fixed content-addressed commitment can make substitutions more detectable, but the surrounding authority model matters.
Is putting a document hash on-chain a trustworthy certificate?
It can support integrity checking for exact bytes under appropriate assumptions. The issuer’s authority, document truth, signature validity, revocation and privacy require additional checks.
If a gateway is down, is my file lost?
Not necessarily. A gateway is one retrieval route. Other providers may still hold and serve matching data. If no verified copy survives, however, the identifier alone cannot restore the content.
Can on-chain storage guarantee confidentiality?
Not by itself. Public replicated data may be widely visible. Encryption and controlled key access can protect content under their assumptions, while storage availability remains a separate requirement.
Is a hash of personal information always safe to publish?
No. Predictable inputs, context and linked information can sometimes undermine privacy. A system should evaluate the actual identifiability risk and applicable retention obligations.
What is the difference between storage and data availability?
Storage concerns who retains bytes. Data availability concerns whether the necessary information is accessible to those who need to verify or reconstruct a state or object under a protocol or service model. Related concepts, but not interchangeable guarantees.
What should I ask before trusting a “permanent blockchain archive”?
Ask exactly what is on-chain, where originals are held, who maintains independent copies, when retrieval was last tested, and how privacy, corrections and exit plans are handled. A permanent-looking identifier is only one part of that answer.
Primary sources and next reading
The IPFS Content Identifiers guide, Persistence guide and Pinning guide define the difference between content identity and retaining retrievable bytes. Ethereum’s Decentralized Storage and Anatomy of Smart Contracts help readers distinguish code, persistent contract state and bulk files. The ERC-721 standard specifies the optional metadata URI interface relevant to many NFTs.
Within eduKateSG, continue to Content-Addressed Blockchain Files: Verify Required Blocks Before Reconstructing, Blockchain Data Protection: Trace Every Copy Before Promising Deletion and Verifying an Education Credential. For the companion reader questions, see Why a QR Code Cannot Prove a Product Is Genuine and Why Two Block Explorers May Disagree.
One sentence captures the mechanism: a ledger may record a trustworthy reference to a file, but the file remains available only if the necessary bytes are actually preserved and retrievable. Knowing what the identifier proves is the beginning of good evidence; knowing who holds the data is what makes the evidence usable later.