Custom functions

Last updated: Apr-20-2023

Cloudinary supports injecting a custom function into the image transformation pipeline. You can either use a remote function/lambda as your source, run a WebAssembly function from a compiled wasm file uploaded to your product environment, or use a jq filter to select an asset to deliver.

To specify a custom function to call, use the custom_function parameter (fn in URLs). The parameter accepts an object detailing the function to inject as follows:

Parameter Description
function_type The type of function to run, either 'remote', 'select', 'render' or 'wasm'.
source The source of the custom function, either the public_id of the wasm file, the URL of the remote function, the video rendering parameters, or the jq filter to use.

Once requested, derived images from custom functions are cached like any other derived images generated by Cloudinary: modifying your custom function will not generate a new image for the same dynamic URL as the URL itself has not changed. If you need to bypass this issue when you change a custom function, we recommend adding a version component to the Cloudinary URL.

WebAssembly functions

Compiled wasm files may be uploaded as raw authenticated resources to your Cloudinary product environment and then referenced in a custom function. Use the custom_function parameter with the function_type set to "wasm" (fn_wasm in URLs), and the source parameter set to the public_id of your compiled wasm file. If the public ID includes slashes, replace the slashes with colons (e.g., custom/example.wasm becomes custom:example.wasm).

For example, to deliver the 'sample' image after running the WebAssembly functions located in a compiled wasm file:

  1. Upload your compiled wasm file to your product environment as an authenticated raw file:

  2. Deliver the sample image after running the WebAssembly functions located in your now uploaded my_example.wasm file:

    The code generates a URL similar to:

WebAssembly contract

The samples below are given in the Rust programming language which is then compiled to a wasm target - but this can be achieved with any language that compiles to .wasm.

Your wasm file should be compiled for a server environment (not JavaScript), and the WebAssembly functions in your compiled wasm file need to comply with a specific interface - you must provide the following 3 public functions:

1. alloc

Your alloc method needs to allocate memory according to the size given and then return a pointer to the allocated memory.

2. dealloc

Your dealloc method should deallocate memory at the given pointer, according to the size given.

3. transform

Your transform method should include the code you want to perform the actual transformation of the image. The method receives the image width, image height, a pointer to the pixel buffer (of size = width x height x 4) where the pixel scheme is guaranteed to be RGBA interleaved, a pointer to the metadata, and the metadata size.

Metadata is given as a JSON structure which contains:

  • current_page - The current page in a multi-paged asset.
  • variables - Any user-defined variables specified as part of the transformation.

You can pass files to WebAssembly functions as base64 encoded strings using file reference variables, as shown in this example.

The transform function must return a pointer to the output buffer that contains the following information: width as a 32 bit BigEndian, followed by the height as a 32 bit BigEndian, followed by the image pixel buffer (RGBA scheme again).

WebAssembly example

The following example applies a blur effect to an image:

Remote functions

You can call a remote function/lambda as part of the transformation chain. The remote function receives an input image file (PNG) along with metadata, and must return an image file (optionally along with metadata also). Use the custom_function parameter with the function_type set to "remote" (fn_remote in URLs), and the source parameter set to the URL of the custom function. The delivery URL also needs to be signed, which means also adding the sign_url parameter set to "true" to the SDK method.

The image is sent in the PNG format to the remote function, even if the uploaded image is in a different format.

For example, to deliver the 'sample' image after running the remote function located at 'https://my.example.custom/function':

The code generates a URL similar to:

The Cloudinary SDKs automatically generate a base64 encoded URL from the source parameter: you will need to supply the source URL in base64 with padding if you generate the delivery URL in your own code.

Request structure

The URL of your remote function receives the following information in the HTTP POST request from Cloudinary:

Request headers:

  • X-Cld-Timestamp - an integer value representing the time the request was sent in Unix time.
  • X-Cld-Signature - a signature string for verification: the string is an SHA-1 Hex-Digest of the request body + timestamp + your API secret.

Request body:

  • file - the (binary) image file.
  • metadata - a JSON structure that includes the current_page, tags, coordinates (each key represents a coordinate source) and variables (key-value pairs representing variable names and values). For example:

Response structure

Your response should include the image Content-Type in the header and the image data in the body. For example, if using API Gateway to host your remote function then the response would be similar to:

The body of your response can contain just the image data or you can include new metadata as follows:

  1. Start the response body with the string 'CLDB'.
  2. Add 4 bytes (BigEndian) describing the byte length of the result image buffer.
  3. Add the image buffer.
  4. Add 4 bytes (BigEndian) describing the byte length of the result metadata JSON buffer.
  5. Add the metadata buffer.

Sample remote function

The following code is an example of a remote function that is hosted on AWS lambda behind an API gateway and is written in JavaScript. The function resizes an image to a width of 314px and adds a text overlay of the current date (subsequent requests will retrieve this image from the CDN cache and the date will not change). It also returns new metadata:

Select custom functions

Currently only URL syntax is supported - not supported by the Cloudinary SDKs.

The select custom function (fn_select in URLs) can be used to deliver assets based on filters using tags and structured metadata. This feature can be used for eCommerce use cases such as:

  • Assigning tags to all assets required for a 'product ID' and delivering the main image or video (aka the Hero Image) on Product listing pages (PLPs).
  • Displaying images based on expected position in a product gallery on Product Detail Pages (PDPs). Here, the expected position can be assigned using SMD.
  • Displaying alternate images (or videos) on PLPs when the user hovers on a product tile.
  • Delivering assets using complex logic based on the existence of Structured Metadata.

The general URL syntax takes the form:


  • cloud - your Cloudinary product environment's cloud name.
  • resource_type - the type of resource to deliver, image or video.
  • jq_filter - the jq filter to use for selecting the asset.
  • transformations - (optional) any transformations to apply to the selected asset.
  • tag - the tag for generating the list of assets.

Under the hood, the jq filter is applied to the JSON response from a client-side call to generate a list of all assets with the same tag. The jq filter would most commonly select a single public_id based on the values of structured metadata saved with the assets, but the filter can select based on any of the resource properties returned in the response.

An example of a JSON response snippet, listing assets with the same tag ('samples'):

jq filters

You select the asset by using a jq filter to return a single public ID which will then be delivered to the browser, along with any necessary transformations. jq is a popular command line parser for JSON, and you can create complex filters to fit your needs.

An example jq filter to select an asset where the value of its 'product-hero-image' metadata field is 'yes':

The filter must also be URL safe, so we need to convert it using a 3rd party library or tools such as URL Encode and Decode - Online to get:

Putting all the above in a single URL:

Note that running the jq filter above on the example response, would return the asset with a public_id of cld-sample

Select base64 alternative

Instead of specifying the jq filter as a URL safe string, the select custom function also supports specifying the filter in base64 (url-safe variant), that not only makes the filter URL safe, but also pretty since there won't be any special characters. The syntax is similar to the above, except for using the parameter as fn_select:jqb64 to indicate that it's a base64 encoded filter.

For example:

Preprocessing custom functions

You can insert your custom function earlier in the transformation chain, before Cloudinary does any processing whatsoever on the image. Whereas the remote function option described above is sent an image in PNG format, a preprocessing remote function is sent the original image file, as uploaded to Cloudinary. For example, you can upload images in a format Cloudinary does not support for transformations and use a custom function to return an image format that Cloudinary does support.

Only Remote Functions are supported for preprocessing as described above, except for the following differences:

  1. Use the custom_pre_function parameter (fn_pre in URLs) to call the custom function to preprocess. The parameter accepts the same type of object as the custom_function parameter, detailing the function_type ('remote') and source.
  2. The preprocessing function is sent the original unaltered image, plus any defined variables, and must return an image in a format that Cloudinary supports for transformations.
  3. Any other Cloudinary transformations given are applied to the result of the preprocessing function: the custom_pre_function parameter is applied first, no matter its location in the transformation chain.

For example, to deliver the 'sample' image after preprocessing the remote function located at 'https://my.preprocess.custom/function':

The code generates a URL similar to:

Render function

Video generation with the render function is currently in Beta. There may be minor changes to parameter names or other implementation details before the general access release. We invite you to try it out. We would appreciate any feedback via our support team.

The custom render function is used for passing customization data to the Cloudinary Video generation feature, which lets you programmatically create videos at scale. The process invloves first creating a manifest in JSON format to provide a reusable template to generate multiple videos using different assets, colors and text. The render function is then used to pass the values of the various settings to apply.

The general URL syntax to create a video using a delivery URL takes the form:<cloudname>/video/upload/fn_render:<video-settings>/<global-transformations>/<manifest>.<ext>

See the video generation reference for full details on the relevant options.

An example manifest file may look as follows:

You can now use the same manifest as a template from which to dynamically create new videos, by also using the fn_render parameter in the delivery URL to pass new values for some of the settings.

For example, to generate a video using the manifest shown above, but at a width of 640, a height of 360, and using the following new 'vars' values:

  • bgColor: mediumpurple
  • imageUrl: oldhands
  • titleText: Loving%20and%20caring%20always%20go%20hand%20in%20hand

✔️ Feedback sent!

Rate this page: