Imgix and Image CDN vs Simple Placeholder APIs

Imgix overview

What imgix does and where its placeholder features apply

Imgix works by sitting in front of an image source (typically S3, GCS, or Azure Blob). You give it a base URL, and it transforms images on demand through URL parameters: resize, crop, format, quality, blur, color fill, and more. Its real-time transformation pipeline is fast and the output is aggressively cached.

For LQIP generation, imgix uses the blur parameter (blur=200) combined with width (w=20) to produce a tiny blurred thumbnail that loads in milliseconds. The quality of an imgix LQIP is better than a generated placeholder because the blur is based on the actual image content.

The limitation is the same as with Cloudinary: the source image must already exist at your imgix origin. A missing product photo, an unset user avatar, or a draft blog post with no featured image cannot be represented through imgix transformations. There is no source to transform.

Gaps

The cases imgix cannot handle without a source image

New product listings that are created before photos are taken. User accounts created before a profile photo is uploaded. Blog posts in draft state without a featured image. CMS content that was migrated from a system where images were optional. These are all cases where there is no source asset.

For these cases, you need a placeholder that generates from parameters alone. The onerror handler on any imgix-delivered image also needs a fallback URL. If the source asset is deleted from S3 after imgix has cached a 200 response, the imgix URL will eventually 404 after the cache expires, and the onerror fallback fires.

Using another imgix URL as a fallback creates a dependency chain on the same infrastructure. An imgix-wide outage or origin issue affects both the primary URL and the fallback simultaneously. Fallback URLs should be on independent infrastructure.

Cost

Imgix pricing compared to free placeholder generation

Imgix pricing is based on origin images and transformation variants delivered. The starter plan begins at around $75/month for small volumes. For a site that delivers significant image traffic, imgix is cost-effective relative to its feature set. But using imgix for placeholder images — when a free URL-based API could serve the same bytes — is unnecessary cost.

fallback.pics placeholder URLs are served from Cloudflare's free tier for edge deployment. Generated SVGs are a few hundred bytes; cached responses cost nothing to serve. The placeholder use case does not justify an imgix subscription if that is the only reason you are considering it.

Combined architecture

Using imgix and fallback.pics together

The architecture that covers all cases: imgix for delivery and transformation of images that exist, fallback.pics for images that do not. An image component gets an imgix URL for the src and a fallback.pics URL for the onerror handler. If imgix delivers successfully, the fallback URL is never fetched and costs nothing.

This pattern also applies to LQIP: use imgix's blur parameter for the LQIP state on content with images, and use fallback.pics blur route for content without images. The user experience is consistent — soft loading states in both cases — regardless of whether a source asset exists.

// imgix for real images + fallback.pics for missing/errored
const imgixBase = 'https://yoursite.imgix.net';

function contentImageSrc(
  path: string | null,
  width: number,
  height: number,
): string {
  if (!path) {
    return `https://fallback.pics/api/v1/${width}x${height}/E4E4E7/A1A1AA`;
  }
  return `${imgixBase}/${path}?w=${width}&h=${height}&fit=crop&auto=format`;
}

function lqipSrc(path: string | null, width: number, height: number): string {
  if (!path) {
    return `https://fallback.pics/api/v1/blur/${width}x${height}/E4E4E7/D4D4D8`;
  }
  return `${imgixBase}/${path}?w=20&blur=200&auto=format`;
}

onerror independence

Why fallback URLs should not be on the same CDN as primary images

An onerror fallback URL should come from infrastructure that is independent of your primary image delivery. When your primary CDN has an incident, your fallback URLs are the last line of defense. If they share the same CDN, they fail at the same time.

Cloudflare Workers (which powers fallback.pics) and Cloudflare CDN are different products on the same network, but the Workers runtime is highly isolated from CDN status. More practically, imgix and fallback.pics are different companies with different network paths, making simultaneous outages effectively independent events.

Summary

imgix placeholder vs standalone placeholder API: which to use where

Use imgix for transformation and delivery of source images at scale. Its LQIP blur-up is excellent for content that always has an image. For the missing-image case, use a standalone placeholder API. Keep your fallback URL infrastructure separate from your primary image CDN.

https://fallback.pics/docs/
https://fallback.pics/placeholder-image-api/
https://fallback.pics/blog/cloudinary-vs-generated-placeholders/
https://fallback.pics/blog/lqip-blur-up-placeholders-layout-shift/