Cloudinary vs Generated Placeholder URLs for Fallbacks

What Cloudinary does

Cloudinary image transformations vs standalone placeholder generation

Cloudinary's transformation API is powerful for operations on existing images: resize, crop, format convert, apply effects, overlay text, generate AI thumbnails. For placeholders, you can use the e_pixelate, e_blur, or b_color Cloudinary transformations on a source image to create a low-fidelity loading state.

The key word is source image. Cloudinary transformations operate on images you have already uploaded to your Cloudinary media library. If a product image has not been uploaded yet, or if the upload failed, there is no source for Cloudinary to transform. You cannot use Cloudinary's transformation API to generate a placeholder for missing content that has no source asset.

This is the fundamental gap. Cloudinary handles the case where you have an image and want a transformed variant. A standalone placeholder API handles the case where no image exists at all — a new product listing, a draft blog post, an unassigned user avatar.

Cloudinary placeholders

Cloudinary LQIP and blur-up for existing images

Cloudinary's blur-up pattern works well for images that exist. Generate a LQIP (Low Quality Image Placeholder) by requesting your image with e_blur:2000 and w_20 — a 20-pixel-wide blurred thumbnail that compresses to under 1KB. Load this immediately, then swap to the full image. Cloudinary's client SDK automates this.

This LQIP approach is genuinely excellent for content that will always have an image. It outperforms fallback.pics blur placeholders in visual fidelity because the LQIP is derived from the actual image rather than a generic pattern. Use Cloudinary's built-in LQIP where images exist; use fallback.pics for the missing-image case.

// Cloudinary LQIP for an existing image
const cloudinaryLqip = cloudinary.url('product/shoes-001', {
  transformation: [{ width: 20, effect: 'blur:2000', quality: 'auto' }],
});

// fallback.pics for a product with no image uploaded yet
const missingProductFallback =
  'https://fallback.pics/api/v1/400x400/E4E4E7/A1A1AA?text=No+Image';

// Combined: LQIP if image exists, generated placeholder if not
function getProductImageSrc(cloudinaryId: string | null): string {
  if (!cloudinaryId) return missingProductFallback;
  return cloudinary.url(cloudinaryId, { width: 400, height: 400, crop: 'fill' });
}

Cost model

Cloudinary pricing vs free placeholder generation

Cloudinary charges per transformation and per stored asset. The free tier covers 25 credits/month; transformation-heavy workflows consume credits quickly. For a product catalog where every image has a Cloudinary asset, the LQIP generation adds measurable transformation cost.

Standalone placeholder APIs like fallback.pics generate images with no per-transformation fee. A placeholder URL is the same cost whether it is served once or a million times. For fallback scenarios — which by definition fire only when something goes wrong — there is no reason to pay per-transformation costs.

Integration

Using both Cloudinary and fallback.pics in the same application

The practical architecture for a content-heavy application is: Cloudinary for all transformations on existing images (resize, crop, format, LQIP), and fallback.pics for all cases where no Cloudinary asset exists. The two services are complementary, not competing.

In practice, this means your image component checks whether a Cloudinary public ID is present. If yes, use Cloudinary's URL builder for the src. If no, fall back to a fallback.pics URL at the same dimensions. The onerror handler on the Cloudinary URL also points to fallback.pics in case the asset exists but fails to deliver.

import { buildUrl } from '@cloudinary/url-gen';
import { Resize } from '@cloudinary/url-gen/actions/resize';

function ProductImage({
  cloudinaryId,
  alt,
  width,
  height,
}: {
  cloudinaryId: string | null;
  alt: string;
  width: number;
  height: number;
}) {
  const fallback = `https://fallback.pics/api/v1/${width}x${height}/E4E4E7/A1A1AA?text=${encodeURIComponent(alt)}`;
  const [src, setSrc] = React.useState(
    cloudinaryId
      ? buildUrl(cloudinaryId, { transformation: Resize.fill(width, height) })
      : fallback,
  );

  return (
    <img
      src={src}
      alt={alt}
      width={width}
      height={height}
      onError={() => setSrc(fallback)}
    />
  );
}

Uptime

Fallback reliability: why your fallback URL must not depend on Cloudinary

Cloudinary has had documented outages. During an outage, transformation requests fail. If your fallback images are also Cloudinary URLs — generated via transformation from a placeholder source image in your library — they fail at the same time as your real images. The fallback defeats its own purpose.

For onerror fallback URLs specifically, use a service with a different infrastructure stack. Cloudinary outages affecting your main image delivery do not propagate to Cloudflare Workers serving fallback.pics URLs. Infrastructure diversity is a reliability feature, not just a cost consideration.

Summary

Cloudinary vs generated placeholders: which for what

Cloudinary is the right tool for transforming and delivering images that exist. Its LQIP blur-up pattern is excellent for content with guaranteed source assets. fallback.pics fills the structural gap: images that do not exist, uploads that failed, and draft content that has never had a photo. For onerror fallbacks in production, keeping the fallback URL independent of your main image CDN is a sound reliability pattern.

https://fallback.pics/docs/
https://fallback.pics/placeholder-image-api/
https://fallback.pics/blog/blur-placeholder-loading-states/
https://fallback.pics/blog/lqip-blur-up-placeholders-layout-shift/