Imgix APIsRendering APIOverview

Rendering API Overview

The Imgix Rendering API can optimize your images, improve your page speed, and make it easy to create responsive designs.

By adding these parameters to your image URLs, you can enhance, resize and crop images, compress them and change format for better performance, create complex compositions, and extract useful metadata. These operations can be applied programmatically in real time across entire image libraries, removing the need to batch process or maintain multiple copies of an image to match device breakpoints.

This section of the documentation describes all of the parameters available in the Rendering API and includes live examples that you can experiment with. For more detailed information about how to implement for specific use cases, please see the Tutorials section. To learn more about the basics of serving images once you’ve set up the service, read the Serving Images guide

Base64 Variants

All Imgix parameter values (with the exception of auto and ch) can be encoded using a URL-safe Base64 scheme. To use this approach, pre-encode the value, and append 64 to the end of the parameter name. For example, txt becomes txt64.

Please keep in mind that this uses the URL-safe alphabet as defined in RFC 4648, and that any padding characters (=) must be omitted from the final encoded value.

Here’s an example:

Original
?txt=Hello%2C%20World!

becomes the following when URL-safe Base64 encoded:

Base64 encoded
?txt64=SGVsbG8sIFdvcmxkIQ

Generating Base64-encoded parameters is easy in many languages. Here are a few code examples:

const encodedString = btoa('Hello, World!')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '');
 
console.log(encodedString);
//=> 'SGVsbG8sIFdvcmxkIQ'

Many of the Imgix client libraries automatically encode strings passed to Base64 variant parameters. Check whichever library you’re using for specific details of its implementation.

Colors

Some parameters, such as bg and border, accept colors as values. Colors can be expressed as either:

  • A color keyword, such as “orange” or “lightsteelblue”. See the full list of accepted color keywords.
  • 3- (RGB), 4- (ARGB) 6- (RRGGBB) or 8-digit (AARRGGBB) hexadecimal values. The “A” in a 4- or 8-digit hex value represents the color’s alpha transparency. When outputting image formats that do not support transparency (such as JPEG), set this value to a non-transparent color.

Relative Lengths

Many length parameters accept either a pixel value or a fraction of the image. How the number is written decides which one you get.

Written asMeans
An integer: 20, 1Pixels, multiplied by dpr
A decimal with a dot, 0 to 1: 0.05, .5, 1.0A fraction, never multiplied by dpr
A decimal from -1 to 0A negative fraction, for layer offsets only
Anything else, such as 2.5Pixels

So mark-pad=1 is one pixel, while mark-pad=1.0 is the whole frame. This deliberately differs from w, h and rect, where w=1 already means 100%.

Writing a layout in fractions means one URL holds its proportions at every width and every dpr, which is what makes a single badge or caption URL safe to use across a srcset.

These parameters take a fraction, each of the dimension named:

ParametersFraction of
mark-x, mark-y, blend-x, blend-yThe base image’s width or height
mark-pad, blend-pad, txt-padThe base image, per axis
pad and its per-side formsThe wxh box when set, otherwise the picture
border and its per-side forms, border-radius, border-radius-inner, border-stroke-sizeThe shorter side of the frame
txt-widthThe base image’s width
txt-lead, txt-line, txt-shadThe font size, as an em

mark-anchor and blend-anchor choose which point of a layer an explicit mark-x/mark-y or blend-x/blend-y lands on.

A Note for Existing URLs

Before September 30, 2026, a decimal between -1 and 1 on these parameters was read as a pixel value. mark-pad=0.5 meant half a pixel and txt-line=0.8 meant a 0.8 px outline; they now mean half the frame and 0.8 em. Decimal border widths and corner-radius parts used to be rejected outright and now draw.

Metadata

By default, Imgix will strip most metadata (EXIF data, geolocation, etc.) from any image processed by Imgix. The only exceptions are for images that are served via passthrough or assets served without appended parameters.

To preserve IPTC/XMP metadata on your images, use the iptc parameter with iptc=allow. To preserve metadata on every image without adding the parameter, contact Support to enable Always passthrough.

Limits

  • Canvas size: The maximum supported canvas size is 8192px by 8192px. If your image is larger than the limit, it will be resized to fit within the limit before any other Imgix operations occur. If you require a larger canvas size, please contact us.
  • ** Input file size **: For optimal performance, we recommend keeping input files under 100 MB **. While Imgix can handle files up to a soft limit of 500 MB, processing times may be greatly delayed for large files. Files that are too large may receive a 413 Entity Too Large error. If you require a larger input file size, please contact us.