How to Choose Image Storage

Image storage is not the same as normal file storage.

Normal files mainly need upload, download, permissions, and persistence. Images also need resizing, format conversion, compression, cropping, responsive delivery, CDN, caching, lazy loading, thumbnails, and page performance.

If your product only has a few internal attachments, normal object storage is enough. But if images affect user experience, SEO, page speed, and bandwidth cost, image storage needs more careful design.

This article references official docs and product materials:

• Cloudinary Image Transformations
• Cloudinary Image Optimization
• ImageKit Image Transformations
• ImageKit Image Optimization
• Cloudflare Images Transformations
• Cloudflare R2
• Amazon S3 Presigned URLs

First Separate Image Types

Not all images should use the same solution.

Product images can be grouped into four types:

Public images: avatars, covers, article images, product images
Private images: IDs, contract screenshots, internal attachments, user-private images
Processed images: thumbnails, crops, compressed images, watermarked images
Temporary images: import previews, AI-generated intermediates, short-lived sharing images

Public images care about speed and caching. Private images care about permission and temporary access. Processed images care about variant management. Temporary images care about lifecycle and cleanup.

Classify first, then choose technology. Otherwise you may overcomplicate simple images or accidentally expose sensitive ones.

Option 1: Object Storage Plus CDN

The most basic option is storing images in object storage and delivering them through a CDN.

Common combinations include S3 plus CloudFront, R2 plus Cloudflare, OSS plus CDN, COS plus CDN, and similar setups.

This works when you want control over storage structure, permissions, cost, and processing flow. Uploads can use presigned URLs. Access can use public CDN or private temporary URLs.

Pros:

Cost control
Clear structure
Good for storing many originals
Easy to unify with file storage

Cons:

You handle compression, cropping, and format conversion
You generate thumbnails and multiple sizes
You design cache strategy
More engineering and debugging cost

If image volume is moderate or the team has engineering capacity, this is a solid option.

Option 2: Image Cloud Service

Image cloud services specialize in upload, transformation, optimization, and delivery.

Cloudinary's docs show URL-based image transformations. ImageKit also provides URL parameter-based transformations and optimization. Cloudflare Images provides compression, format conversion, resizing, and cropping.

The value is that you do not need to build much image processing logic yourself.

Good fit:

Image experience is important
Need many sizes, formats, and crops
Need fast launch
Want automatic WebP / AVIF optimization
Want less image processing operations

The tradeoffs are cost, platform lock-in, and transformation billing rules.

Option 3: Object Storage Plus Optimization Layer

Many products can use a hybrid approach.

Store originals in object storage, then put an image optimization service or CDN transformation layer in front. This keeps control over original assets while adding optimization capability.

For example, originals live in S3 or R2, while Cloudflare, ImageKit, Cloudinary, or your own image service generates sizes on delivery.

This is useful when images become important, but you do not want all assets fully managed by one image platform.

The key is to design source images, derived images, caching, and invalidation rules.

Separate Public and Private Images

Public images can be cached for a long time and served through public CDN. Examples include avatars, article covers, product screenshots, and public template images.

Private images should not be protected only by “long URLs.” Access should first pass your permission check, then return a temporary URL or controlled download response.

Especially:

Invoice images
ID images
Contract screenshots
Internal document screenshots
Private user uploads

These should live in private buckets or private paths, not mixed with public images.

Should You Keep Originals?

Many image systems keep the original file and generate display versions.

Keeping originals lets you reprocess later, generate new sizes, change compression, and support new formats. The cost is more storage.

If an image is an important user asset, keep the original. If it is temporary preview, one-time thumbnail, or cache output, you can keep only processed versions or use lifecycle cleanup.

Ask: will we need to regenerate it later? Is it a user asset? Can it be recovered after deletion?

Define Image Variant Rules

Image variants are different sizes, formats, and crops.

Examples:

avatar_64
avatar_256
cover_1200x630
thumbnail_320
original

Do not generate random sizes throughout code. Random sizes create messy caches, hard cleanup, and unpredictable cost.

Early on, define a small set: avatar, small thumbnail, large thumbnail, list image, detail image, and social sharing image. Add new sizes only when needed.

Format and Compression Affect Performance

Images have a large impact on page speed.

JPEG, PNG, WebP, and AVIF all fit different scenarios. Modern image services can often choose a better format based on browser capability.

Cloudinary and ImageKit optimization docs emphasize image optimization for web performance. Cloudflare Images docs also describe compression, efficient format conversion, and resizing for different devices.

You do not have to manually handle every format, but your image system should support automatic optimization.

Design Caching and Invalidation

Public images should usually be cached aggressively. The question is: what happens when the image changes?

Common solutions use versioned URLs:

/images/avatar/user_123_v2.webp
/images/product/abc?v=20260531

Or generate a new object key on update instead of overwriting the old file.

If you overwrite the same URL, CDN and browser cache may keep showing the old image for a long time.

Frequently updated images need explicit cache invalidation strategy.

Cost Is More Than Storage

Image cost includes:

Original storage
Derived image storage
Transformation count
CDN bandwidth
Origin egress
Request count
Cache misses
Cross-region access

Some image services charge by transformation, storage, bandwidth, or request count. Estimate your product's image access pattern early.

If reads are much higher than uploads, CDN and caching matter. If you generate many variants, transformation cost matters. If originals are large, compression and upload limits matter.

A Simple Decision Rule

Use this rule:

Few images, mostly internal attachments: object storage is enough
Many public images, high traffic: object storage plus CDN
Many crops, formats, and optimizations: image cloud service
Want control plus optimization: object storage plus optimization layer
Many private images: private object storage plus temporary access URL
Images are core experience: prefer mature image platform

Do not introduce a heavy system for a few images. But do not keep using a temporary setup when images become a core experience.

Final Thoughts

Image storage is not just “where to put images.” It is how images are uploaded, processed, accessed, cached, updated, deleted, and billed.

A safe starting point is: originals in object storage, metadata in the database, public images through CDN, private images through temporary access, common sizes defined early, and optimization handled by a mature service or clear background jobs.

Next, we continue with delivery infrastructure: Do You Need a CDN?.