Storing Images and Metadata for Web3 Apps

Almost every Web3 app handles images and metadata: NFT artwork, token logos, profile pictures, project banners, game items and user uploads. Where that data lives decides whether it loads quickly, stays available for years and can be trusted not to change unexpectedly. Choosing storage deliberately saves painful migrations later.

What needs storing

Data	Examples	Typical requirements
Token metadata	Name, description, attributes	Stable, verifiable
Media files	Artwork, logos, animations	Durable, fast to load
User uploads	Profile images, logos	Moderation, size limits
App assets	Icons, illustrations	Fast delivery, caching
Documents	Whitepapers, reports	Versioning, availability

Different data types can use different storage strategies.

Option 1: Traditional servers and object storage

Storing files on your own servers or cloud object storage is simple and fast. Content delivery networks make global loading quick.

Strengths: easy to manage, flexible, cheap for moderate volumes. Weaknesses: files can change or disappear if the operator changes them or stops paying. Users must trust the operator.

This option works well for app assets, user uploads that need moderation and content where mutability is acceptable.

Option 2: Content-addressed storage networks

Content-addressed storage identifies files by a hash of their content. If a file changes, its address changes. References to a content address always point to the same file.

Strengths: verifiable integrity, decentralised retrieval options. Weaknesses: files must be kept available through pinning services or persistent storage arrangements. Retrieval speed can vary without good gateways.

This option suits NFT metadata and media where integrity matters.

Option 3: On-chain storage

Some projects store data directly in smart contracts, often as compact SVG images or generative code.

Strengths: maximum durability as long as the blockchain exists, no external dependencies. Weaknesses: expensive, limited size, harder to update.

This option fits small, high-value artworks and projects where permanence is central to the concept.

Mixing approaches

Many apps combine options:

1. On-chain references to content-addressed metadata
2. Content-addressed media with a fast CDN cache in front
3. Traditional storage for app assets and moderated uploads
4. Periodic backups of critical files in multiple locations

The key question for each file is who needs to trust that it will stay the same.

Handling user uploads safely

User-uploaded images need extra care:

• Restrict file types to safe formats such as PNG, JPEG and WebP
• Avoid accepting SVG uploads, which can contain scripts
• Resize and re-encode images server-side or client-side
• Enforce size limits
• Serve uploads with strict content-type headers
• Moderate content before or after publishing, depending on risk

Metadata mutability

Decide whether metadata can change. Some projects intentionally keep metadata updatable, for example to reveal NFTs after mint or evolve game items. Others freeze metadata to guarantee collectors a permanent result. Communicate the choice clearly.

Performance

Whatever storage you choose, deliver media efficiently. Generate thumbnails, use modern image formats, lazy-load images below the fold and cache aggressively.

Plan for the long term

Storage decisions last longer than most teams expect. Collections minted today may be viewed for years, and projects change hosting providers, domains and teams along the way. Document where every category of file lives, who pays for storage, how backups work and how references would be migrated if a provider shut down. A short storage plan written early can prevent a stressful emergency later.

A practical example

Proud Globe accepts square logo uploads for pins, resizes them to small WebP images in the browser before upload, rejects SVG and serves logos with strict headers. Journal images are optimised WebP files served from the edge. You can try the logo upload on the claim page.