Cloudinary Blog

Automated JavaScript Image Transformation and Management

Automated JavaScript Image Transformation and Management


Cloudinary’s JavaScript library accelerates web development by providing automated JavaScript image manipulation and management with a few lines of code. The newly released version streamlines the library by providing a much requested jQuery-free core library. At the same time it is fully backward compatible with previous versions. The new library is further enhanced with classes and a chainable API, making the implementation of Cloudinary functionality in your application easier (and more enjoyable!).


Virtually all websites incorporate images and videos in their web pages. With the proliferation of web platforms, devices and rising user expectations, handling media is an increasingly complex task. Services such as Cloudinary alleviate the pain by relieving the developer from having to manually manipulate images, respond to device and layout constraints, and manage storage and availability concerns.

A typical mistake made by novice developers is to provide full size images on the web page. This guaranties that the page will look great on the highest resolution, but at a large cost to download and response times - not to mention bandwidth costs.

The easiest solution - using JavaScript image manipulation software to create a smaller resolution version of each image - is quickly revealed to be an exponentially difficult task. For one thing, you have to code your web page to display the right image file. Furthermore, you have to keep track of all files related to the same source image. And any change in layout may require rescaling and re-cropping.

How to Optimize for Page Load Speed

Rinse and repeat for each and every image.

Cloudinary’s JavaScript library essentially eliminates this nightmare.

Cloudinary’s strength is largely due to its ability to transform images using a simply coded URL. For example, adding c_scale,w_500 to the URL will scale the image to a width of - you guessed it - 500 pixels. The image is automatically scaled and cached on a CDN, ready to be served.

Cloudinary’s JavaScript API  provides the functionality required to programmatically declare the required transformations and generate Cloudinary resource URLs. For example, the aforementioned transformation can be expressed using the following configuration object: {crop: “scale”, width: 500}.

Creating the imageURL (which will also generate a new image) is simple and intuitive:

Copy to clipboard
cl.url( "elephants.jpg", {crop: "scale", width: 500});

Scaled down elephants image to 500 pixels

You can also generate the entire image tag:

Copy to clipboard
cl.image( "elephants.jpg", {crop: "scale", width: 500});
// <img src=",w_500/elephants.jpg" width="500">

For more artistic results:

Copy to clipboard
var artistic =

cl.image("elephants.jpg", artistic);
// <img src=",e_oil_paint:50,r_max,w_500/elephants.jpg" >

Oil paint image effect

Copy to clipboard
cl.image("horses.jpg", artistic);
// <img src=",e_oil_paint:50,r_max,w_500/horses.jpg" >

Oil paint effect of the horses photo

See what I mean?

In addition, the SDK provides the functionality required to upload images from the browser directly to the cloud, and apply responsive behavior to the displayed images. For more information on the available SDKs and media transformation options, see Cloudinary’s documentation.

Main Features

The Cloudinary JavaScript library functionality is represented using several classes.

The main class, Cloudinary, provides an API for:

  • Generating resource URLs.
  • Generating HTML.
  • Generating transformation strings.
  • Enabling responsive behavior.

In addition, other classes encapsulate specific behavior:

  • Transformation - generates and represents transformations.
  • Configuration - manages the Cloudinary API configuration.
  • HtmlTag, ImageTag, VideoTag - generates HTML tags.
  • Util - various utility functions.

After providing basic configuration values, the API is ready to be used.

Here are a few examples:

Copy to clipboard
var cl = { cloud_name: "demo"});

var d = document.getElementById("my_div");

d.appendChild( cl.imageTag("sample", {crop: "scale", width: 200}).toDOM());

var i = document.getElementById(my_image);

i.src = cl.url( "sample", {crop: "scale", width: 200, angle: 30});

Rejuvenating a library

When we first wrote our JavaScript library, it was designed as a jQuery plugin. Virtually all JavaScript developers are familiar with jQuery: it is one of the most popular JavaScript libraries and has a large following. It is designed by and large for client side HTML/DOM manipulation, but includes many useful general purpose functions. jQuery takes the hassle away from many of the woes of web development and has served developers well. The jQuery library also provides browser compatibility by handling special cases and ensuring that the JavaScript code will run on virtually all clients.

However with the recent rise in the number of JavaScript libraries, frameworks and, well, tastes, we have also received many requests to create a jQuery-less library.

The decisions facing one in the task of redesigning a JavaScript library are numerous and daunting. Backward compatibility vs. a clean break? native JavaScript vs. CoffeeScript / TypeScript? lodash, underscore, or implement your own solutions? Npm, Bower or both? Grunt, Gulp, npm? RequireJS, CommonJS, webpack, browserify? - well, you get the point.

Javascript framework and tools

Too many choices

Needless to say each choice you make will provoke praise from one camp and battle cries from the other…

Backward Compatibility

Backward compatibility is obviously a big issue. Our philosophy is to let our customers enjoy new features with minimal code changes - if any. The nature of our service also requires that our libraries support a wider range of platforms and browser versions than normally needed. To this end, the new library was designed to be a drop-in replacement to the existing library. This decision has put some constraints on the design of the library - but we were happy (and proud) to have accomplished it in full.

Old version:

Copy to clipboard
$.cloudinary.url(my_image, {width: 100});

New version:

Copy to clipboard
$.cloudinary.url(my_image, {width: 100});

Backward compatibility, anyone? the new library is a drop-in replacement.

The cloudinary_js library is provided in plain javascript 5. This is important to ensure it will run smoothly regardless of the browser the end user is using. During the development phase, it is often easier to code in a higher function variation of the language.

Early on we made the decision to write the new code in CoffeeScript. While ES2015 (the artist formally known as ES6) was already rolling out, maintaining backward compatibility meant that we would have to “compile” the code anyway. CoffeeScript has its own shortcomings but its familiarity to Rails developers, and the fact the our NodeJS library was written in CoffeeScript, made it a comfortable choice. Besides, comprehensions are cool!

CoffeeScript and ES2015 both allow the creation of classes and objects. Syntax may vary (as does the implementation of class inheritance) but the result is similar. In fact both are mainly syntactic-sugar to a functionality that already existed in “native” JavaScript.

The new library groups functionality into classes. One of the neat benefits is the ability to chain function calls, making the code more descriptive.

The following code, for example, configures the Cloudinary API to use the cloud “demo”.

It then creates an image tag for the “sample” image, scaled to a width of 150px, rotated by 15 degrees, and with the “sepia" effect applied.

Copy to clipboard
var cl ={cloud_name: "demo"});
var tag = cl.imageTag("sample").transformation()

Since the code is object oriented (rather than global as in the previous version), it is easy to utilize multiple clouds and accounts in the same application.

The following code creates two image tags drawn from two different clouds (note that while the public ID of the image is the same these could be two completely different images as they are defined in separate clouds).

Copy to clipboard
var someCloud = {cloud_name: "someCloud", secure: true});
var otherCloud = {cloud_name: "otherCloud"});

someCloud.imageTag("sample.jpg"); // <img src="">
otherCloud.imageTag("sample.jpg"); // <img src="">

Utility functions

The JavaScript language has limitations, be it array manipulation or determining an “empty” value. Some of these limitations were addressed in ES2015, but as a JavaScript developer you always have to be on your toes making sure that the feature you are using will be supported in all foreseeable environments.

Libraries such as lodash take the edge off by providing an implementation of features when the runtime environment does not support them. Because jQuery support was still required for the Cloudinary jQuery plugin, and because we anticipated frowns on the use of lodash, we designed the library so that lodash is not called directly but through the “util” interface. This allows us to switch between jQuery and lodash when needed. It also allows for the future utilization of a different library, or for a keen programmer to implement “native” code and make the library become fully standalone.

We also created a special shrinkwrapped version of the library which includes a subset of the lodash functions that are required by Cloudinary. The resulting single file is about half the size of a full sourced lodash + Cloudinary.

Uploading a file using JavaScript is basically not a difficult task, but it gets complex quickly and deeply so. To avoid this we have relied in the past on Blueimp’s excellent jQuery-file-upload library. For both backward compatibility and the fact that this library does what it does well, we decided to keep using it. As much as this library is useful however, you can still utilize other upload libraries or write your own code to upload files from the core library. See this example of a pure JavaScript upload to Cloudinary.

New source repositories

There are two common ways to manage dependent libraries in JavaScript: npm and bower. Originally, bower handled client side libraries while npm, as its name suggests (Node Package Manager) was managing server side libraries. Today npm is used to manage client side libraries too. In fact jQuery, which used to have its own repository, moved its plugins to npm.

In order to serve both the core library and the jQuery variant we had to create 3 new github repositories. The main reason was that bower relies directly on the github release information, which means you cannot serve two packages from the same repository.

The main repository which includes the source code, issues and pull requests for the Cloudinary JavaScript library is located at cloudinary_js. In order to support existing websites that relied on the previous version of this library, it includes a backward compatible distribution format.

The new JavaScript API is provided in 3 distribution packages:

Github Repository

Package name




Core Cloudinary Library.

Use this if you do not intend to use jQuery.



Core Library + jQuery plugin



Core Library + jQuery plugin

+ Blueimp File Upload adapter

The same package names are used in both bower and NPM.

This API reference is generated directly from the code and complements the documentation on our main website.


The management of images and other media resources is an important part of modern web and mobile development. The Cloudinary JavaScript library significantly reduces the workload by automating the manipulation and delivery of the resources.

The new version of the library includes 3 distributions: the core library, the jQuery plugin, and the File Upload plugin.

The library also introduces a new API that allows the developer to chain function calls and use multiple accounts in the same application.

Head over and give it a try at cloudinary_js!

We’re looking forward to hearing your impressions!

Elephants image is under CC0 license. The source of the image is here.

Recent Blog Posts

On-Demand Viewing of Live Video Presents New Opportunities

In early 2020, Cloudinary was planning its fourth annual ImageCon conference, a two-day event in the heart of San Francisco, where we’d congregate with curious digital-media minds to brainstorm best practices for media management. Instead, the COVID-19 pandemic forced the entirety of ImageCon 2020 online. As with all other events being planned, we had to overhaul the content to be communicated on video. Gratifyingly, we found the right partner—the event platform Bizzabo—to turn that into a reality.

Read more
Why the Future of E-commerce Is Live

In a previous post, I discussed how “going live” is gaining popularity across industries and verticals. What began as a way for gamers to jam together has evolved into a medium for broader entertainment and business purposes. To continue the conversation, this post unpacks the current trends of shoppable live streams to shine a light on how brands are leveraging “lives” to connect with shoppers in new ways.

Read more
An Overview of Live-Streaming Video Trends

“Let’s go live.” For decades, that’s what newscasters say as they cut to real-time footage of a colleague reporting in the field. The live-video feed adds visual interest and perspective to a story beyond what can be communicated by someone sitting behind the news desk. In the same way, live-streaming video nowadays adds context to other consumer environments. From gaming and events to shopping and social media, “going live” enhances everyday experiences, and it’s something anyone can do with relative ease.

Read more
Readying Live Streams for Video on Demand

When planning a live broadcast or stream, companies often overlook the redistribution phase, but live-stream videos are useful well beyond their initial streaming. Why? Because not everyone watches the first run. For a wider audience, it makes sense to repost live content on your website under an “events” tab, on YouTube, and other social sites for video on demand (VOD). However, preparing footage for reposting can be a lot of work.

Read more