Automatic Format and Quality in No-Code Delivery

What the setting does

Automatic format and quality selection is a delivery-time policy: the media service chooses how to encode each response while leaving the stored source asset unchanged. In a no-code builder, the setting belongs to media delivery, even when the interface presents it as a toggle or preset rather than as transformation parameters.

That distinction matters because automatic delivery is reversible. A JPEG source can produce a different deliverable format for one request and still remain available as the original source for later transformations. Converting the upload itself to a single format is a separate operation with different consequences.

Automatic format selection happens per request

Cloudinary’s image optimization documentation, checked 2026-08-26, describes f_auto as automatic format selection based on the requesting browser. The request advertises which image formats it can accept, normally through the HTTP Accept header. Cloudinary uses those capabilities, together with the formats enabled for the product environment, to choose a deliverable representation.

The result is not a permanent conversion of the source asset. It is a derived response generated for delivery. Two browsers can therefore request the same transformation URL and receive different encodings. Depending on browser support and product-environment configuration, the selected representation could use formats such as AVIF, JPEG XL, or WebP. If the browser supports none of the optimized formats available to f_auto, Cloudinary documents that delivery falls back to the format named by the URL’s file extension.

Format negotiation has to remain a delivery-time instruction because the requesting browser is unknown during upload. Cloudinary explicitly warns against putting f_auto into an incoming transformation or hiding it inside a named transformation: those operations are resolved before the CDN handles the individual browser request. A named transformation can contain the stable operations, with f_auto chained after it so the CDN can still see and resolve the instruction.

A no-code workflow that converts every upload to one predetermined format is therefore enforcing an upload policy, not performing automatic format selection. That can be intentional, but it should be treated as the separate problem of enforcing a media format policy in no-code upload workflows. It cannot adapt the delivered representation to each request’s capabilities after the upload has finished.

Automatic quality is content- and format-dependent

Automatic quality controls compression rather than choosing a universal quality number. Cloudinary’s transformation parameter reference, checked 2026-08-26, defines q_auto as delivery with an automatically determined quality level and f_auto as delivery in a format selected for the requesting browser.

The quality decision is made from the individual asset’s content and the format being delivered. Different images do not compress equally at one nominal setting, and different encoders do not express quality in identical ways. Automatic quality accounts for those differences by adjusting the compression and encoding settings for the actual content-format combination.

Format and quality selection are therefore coupled even though they perform different jobs. Automatic format chooses an encoding the requester can consume. Automatic quality decides how aggressively to compress the asset in that encoding. When f_auto and q_auto are used together, Cloudinary notes that the chosen format is not necessarily the one producing the smallest possible file. The service can choose a format that provides a different balance between file size and visual quality for that image.

This also means automatic quality is the wrong policy when a delivery contract requires one exact encoder quality value for every response. The setting deliberately allows the output decision to vary with the asset and selected format. It does not change the source asset, and it does not replace decisions about dimensions, cropping, or device-pixel density. Those remain separate delivery concerns, including when responsive image delivery is configured without application code.

The cache must preserve negotiated variants

Automatic format changes the caching model because one URL can identify several valid representations. A cache keyed only by the URL could store the representation produced for the first request and return it to later requesters, even when they advertise different format support.

RFC 9111’s rules for calculating cache keys with Vary, published June 2022, require a cache handling a stored response with Vary not to reuse that response without revalidation unless the nominated request-header fields match the fields from the original request. For format negotiation based on Accept, the cache variation must therefore account for Accept or otherwise partition entries by the negotiated output format.

The practical requirement is exact: a representation selected for one browser must not become the generic cached response for every browser using the same URL. A browser that cannot decode that representation could otherwise receive incompatible bytes from an intermediate cache even though the origin’s negotiation logic would have selected a compatible format.

This requirement applies at every caching layer, not only at the media service’s CDN. If a no-code application builder, site platform, reverse proxy, or service worker caches media responses, that layer assumes responsibility for retaining the relevant variation. A proxy that forwards the delivery request must forward the capability header used for negotiation and preserve the response’s variation semantics. A system that caches by resolved format instead must keep those formats in distinct entries.

Cloudinary resolves f_auto per request at its CDN. Its documentation also states that multiple formats derived for one transformation URL may increase transformation counts and storage use. No fixed multiplier is supplied: the number of derived representations depends on which formats are requested and enabled. Automatic quality may reduce the delivered byte size, but the supplied sources provide no general bandwidth saving or latency benchmark, so neither should be promised for a particular no-code application without measurement.

What the no-code layer controls

A no-code interface can hide the URL syntax, but it does not remove the underlying delivery rules. The relevant configuration must ultimately request automatic format and automatic quality, whether through generated transformation URLs or product-environment defaults supported by the integration. The source must remain the source; browser capability must reach the delivery service; and every cache between that service and the browser must keep negotiated representations separate.

This boundary is worth confirming when evaluating media handling inside a no-code application builder. Some interfaces expose delivery transformations directly, while others only control upload processing or copy an already resolved file into their own storage. Only a path that retains per-request delivery negotiation can provide automatic format selection as defined here.

The next facts to check in a live setup are the generated delivery policy, the actual response format, and the cache variation. Confirm that automatic format and quality are present either in the delivery transformation or the documented default settings. Inspect a normal page request rather than relying only on opening the image URL directly, because Cloudinary notes that direct navigation may not advertise image support in the Accept header as expected. Then verify that downstream caches preserve Accept-based variation or use an equivalent format-aware cache key.