Image Transformation vs imgix: URL Parameters or JSON Pipelines?

A CDN That Transforms vs. an API That Processes

imgix is an image CDN. You point it at your storage — S3, Google Cloud Storage, Azure Blob — and it serves transformed images at the edge via URL parameters. Append ?w=300&h=300&fit=crop&auto=format to an image URL, and imgix resizes, crops, and format-converts on the fly.

It’s good at what it does. If your primary need is serving responsive images in web pages — different sizes for different breakpoints, automatic WebP/AVIF negotiation, lazy loading placeholders — imgix is a mature, well-understood tool.

But serving images in a browser and processing images in a backend pipeline are fundamentally different jobs. imgix is built for the first. The Iteration Layer Image Transformation API is built for the second.

Bring Your Own Storage

imgix doesn’t store your images. You configure a “source” — an S3 bucket, a GCS bucket, a web folder — and imgix proxies requests to that origin, applying transformations on the way through.

This means you need existing storage infrastructure before imgix does anything useful. You manage the bucket, the permissions, the lifecycle policies. If your images live across multiple storage backends, you configure multiple sources. If you want to process an image from an arbitrary URL or a file upload, you first put it somewhere imgix can reach it.

Iteration Layer takes the image directly. Pass a URL or upload the file in the request body. No origin configuration, no storage setup, no proxy layer. The image goes in, the transformed image comes out.

URL Parameters vs. JSON Pipelines

imgix transformations are URL parameters. A complex transformation looks like this:

https://your-source.imgix.net/hero.jpg?w=1200&h=630&fit=crop&crop=faces&auto=format,compress&q=80&sharp=10

This works for embedding in HTML src attributes — the browser fetches the URL, imgix applies the transforms, and the CDN caches the result. For simple resize-and-serve use cases, URL parameters are elegant.

They’re less elegant when transformations get complex. You’re encoding a pipeline into query string syntax. Parameter names are abbreviated (q for quality, w for width, sharp for sharpen). The order of operations is implicit — imgix decides the execution sequence, not you. And some operations can’t be expressed in URL parameters at all.

Iteration Layer uses JSON pipelines. Each operation is an explicit object with named parameters, and operations execute in the order you define them:

import { IterationLayer } from "iterationlayer";

const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const result = await client.transform({
  file: { name: "hero.jpg", url: "https://example.com/hero.jpg" },
  operations: [
    { type: "smart_crop", width_in_px: 1200, height_in_px: 630 },
    { type: "sharpen", sigma: 1.5 },
    { type: "convert", format: "webp", quality: 80 },
    { type: "compress_to_size", max_file_size_in_bytes: 200_000 },
  ],
});

Four operations, explicit execution order, readable parameter names. No abbreviation guessing. And you can chain up to 30 operations in a single request — upscale, crop, sharpen, remove background, convert, compress — as one atomic pipeline.

AI Operations imgix Doesn’t Have

imgix added a crop=faces parameter that uses face detection for crop positioning. That’s about the extent of its AI capabilities.

Iteration Layer ships with AI-powered operations as first-class pipeline steps:

• Smart crop — AI object detection that identifies the subject and crops around it. Not just faces — products, animals, vehicles, whatever the dominant subject is.
• AI upscaling — AI-powered super resolution that upscales images to 2x or 4x while generating realistic detail. Not bicubic interpolation with a filter on top.
• Background removal — AI segmentation that isolates the foreground subject and removes the background. One operation, no external service.

These aren’t add-ons or premium tiers. They’re operations in the same pipeline as resize and convert. Chain them freely: remove the background, upscale to 4x, smart-crop to 1200x630, convert to WebP. One API call.

imgix offers a background removal add-on through their “Rendering API,” but it’s a separate product with separate billing — not a pipeline step you chain with other transforms.

Target-Size Compression

Here’s a problem imgix can’t solve: “I need this image under 200 KB.”

imgix lets you set a quality parameter (q=75), but the resulting file size depends on the image content, resolution, and format. You can’t specify a target size. If your email provider rejects attachments over 500 KB, or your CMS enforces a file size limit, you’re guessing quality values and checking results manually.

Iteration Layer’s compress_to_size operation takes a max_file_size_in_bytes parameter and iteratively adjusts quality and dimensions to hit that target. Specify the constraint, get a file that meets it. No trial and error.

CDN Delivery vs. Processing Output

imgix is fundamentally a CDN. It serves images to browsers. The output is always an HTTP response to a GET request — you get the transformed image bytes as the response body.

This architecture is perfect for <img> tags and CSS background-image URLs. It’s not designed for backend processing workflows where you need to:

• Process a batch of product images and upload the results to a different storage backend
• Chain image processing with other operations — parse a catalog, transform each product image, generate a listing page
• Store the processed image as a file for downstream use in document generation or email assembly
• Run multi-step pipelines where intermediate results matter

Iteration Layer returns the processed image as base64-encoded data in a JSON response. Use it however you want — embed it, download it, pipe it into another API, store it wherever your application needs it. The API doesn’t assume the image ends up in a browser.

The Pricing Elephant

imgix historically charged based on bandwidth — a CDN pricing model that made sense for a CDN product. In 2023, they switched to source-image-count billing. You pay based on the number of unique source images imgix can access, regardless of how many transformations you request or how much bandwidth you use.

For users with large image libraries — e-commerce catalogs, media archives, user-generated content platforms — this was a significant price increase. Some users reported costs jumping 3x to 5x overnight. The imgix community forums and Hacker News threads from that period tell the story.

Source-image-count billing creates a perverse incentive: you pay more for having more images in your origin, even if most of them are rarely accessed. A product catalog with 500,000 SKUs costs the same whether those images get 10 requests a day or 10 million.

24 Operations, One Pipeline

The Iteration Layer Image Transformation API ships with 24 operations across five categories:

Resize and crop:

• Resize, crop, smart crop, pad, trim

Enhance:

• Sharpen, blur, brightness, contrast, saturation, hue rotate, grayscale, invert, auto-enhance

AI:

• AI upscale, background removal, smart crop (AI object detection)

Convert and compress:

• Convert (JPEG, PNG, WebP, GIF, AVIF, HEIF), compress to target size

Compose:

• Rotate, flip

Each operation is a JSON object in the operations array. They execute in order. You control the pipeline, not the service.

When imgix Makes Sense

imgix is the right tool when your problem is serving responsive images in web pages. If you need:

• Automatic format negotiation (WebP for Chrome, AVIF for Safari, JPEG fallback)
• CDN-edge caching with global PoPs
• Simple resize-and-crop via URL parameters in your HTML templates
• Lazy loading placeholders and low-quality image previews

Then imgix does the job well. It’s a CDN product with image transformation bolted on, and for CDN use cases, that’s exactly what you want.

But if your problem is processing images — product photo pipelines, report generation assets, batch optimization, AI-powered transformations — you need an image processing API, not a CDN. Stacking URL parameters in a query string doesn’t scale to 30-operation pipelines with AI upscaling and background removal.

Side-by-Side

Capability	imgix	Iteration Layer
Architecture	CDN proxy with URL-parameter transforms	Processing API with JSON pipelines
Storage	BYOS — configure your own origin	Direct URL or file upload
Transformation syntax	URL query parameters	Ordered JSON operation array
Max operations per request	No explicit limit, but URL length constraints apply	30
AI smart crop	Face detection only	AI object detection (any subject)
AI upscaling	None	AI 2x/4x super-resolution
Background removal	Separate add-on product	Pipeline operation
Target-size compression	Not supported	compress_to_size operation
Output	HTTP image response (CDN)	Base64-encoded JSON
Batch processing	One URL per request	Pipeline per request, no origin setup
Data residency	US-hosted	EU-hosted (Frankfurt)

Get Started

Check the Image Transformation docs for the full operation reference, parameter definitions, and SDK guides. The TypeScript and Python SDKs handle authentication and file uploads — your first pipeline is a few lines of code.

If you’re currently using imgix for backend image processing and hitting the limits of URL-parameter transforms, run the same workflow as a JSON pipeline and compare the results.