Reference Glossary
Dynamic imaging API
An API that generates image renditions on the fly from URL parameters — resize, crop, format, quality — against one stored master, instead of pre-generating every size in advance.
Why it matters in a DAM
A dynamic imaging layer (built into some DAMs, or bolted on via services like Cloudinary or imgix) lets a website request exactly the pixel dimensions and format it needs through a URL convention, computed and cached at request time — removing the need to pre-render and store dozens of fixed-size renditions per asset for every possible layout. At scale, that avoids storing, say, 50,000 product masters × a dozen pre-baked crop sizes each just in case a future template needs them.
A worked example
Common mistake
Teams assume every dynamic imaging URL variant is free once cached and don't constrain which query parameters are accepted, so an unbounded combination of width/height/crop/format values keeps triggering fresh transformation requests — and potentially fresh transformation billing — for URLs nobody deliberately designed, rather than a controlled, predictable size set.
A dynamic imaging API sits between a stored master asset and the person requesting it, reading transformation instructions directly out of the request URL — width, height, crop mode, output format, quality — and generating the resulting image on demand rather than requiring it to already exist as a pre-rendered file. The first request for a given parameter combination triggers the transform and typically caches the result; subsequent identical requests are served from that cache.
This replaces the older DAM pattern of pre-generating a fixed set of renditions for every asset at ingest — a thumbnail, a web size, a print size, and so on — which breaks down the moment a new template or device class needs a size nobody anticipated. With a dynamic imaging API, one master and a URL convention cover effectively any size a future use case might need, without pre-computing storage for combinations that may never actually be requested.
Cloudinary‘s transformation system is a common commercial example of this pattern: action and qualifier parameters embedded in the URL control resizing, cropping, overlays, format conversion, and optimization, with the transformed asset then routed through a CDN. Because transformations are computed per unique parameter set, teams generally need to constrain which parameters are exposed to avoid effectively unlimited variant generation from arbitrary query strings.
Frequently asked
What is a dynamic imaging API?
An API that generates image renditions on the fly from URL parameters — resize, crop, format, quality — against one stored master, instead of pre-generating every size in advance.
What DAM problem does a dynamic imaging API solve?
It removes the need to pre-render and store dozens of fixed-size renditions per asset for every possible layout, avoiding storing, for example, 50,000 product masters times a dozen pre-baked crop sizes each.
How does caching work in a dynamic imaging pipeline?
The first request for a given parameter combination triggers the transform and typically caches the result; subsequent identical requests are served from that cache.
Give an example of a dynamic imaging URL.
example.com/img/sku123.jpg?w=400&h=400&fit=crop returns a 400x400 cropped rendition generated on first request; adding &f=webp&q=80 delivers the same source as WebP at 80% quality.
What's the risk of not constraining accepted URL parameters?
An unbounded combination of width, height, crop, and format values keeps triggering fresh transformation requests, and potentially fresh transformation billing, for variants nobody deliberately designed.
What's a commercial example of this pattern?
Cloudinary's transformation system embeds action and qualifier parameters in the URL to control resizing, cropping, overlays, and format conversion, then routes the transformed asset through a CDN.
Sources
- Dynamic image URLs let developers include transformation instructions as URL parameters; assets are transformed in the cloud, optimized, and then routed through a CDN to the end user. checked 2026-08-07 — Cloudinary — Image Transformations Documentation