Cloudinary Blog

Using Cloudinary to manage all your website’s assets in the Cloud

Digital Asset Management in the Cloud

When we conceived Cloudinary, our vision was to help websites manage all their assets (images, Javascripts, CSS, etc.) in the cloud, easily and effectively. Our initial focus was on image management in the cloud since we've felt that this particular area was significantly underdeveloped. We figured that every web developer would be happy with a solid solution for image uploads, applying image transformations in the Cloud and getting their website's images delivered through a fast CDN.

We've recently taken the plunge and added support for raw file uploads and CDN delivery. In addition to images, you can now use Cloudinary's same simple APIs and dynamic URLs to manage every file in the cloud - CSS, Javascript, PDF, and more. The advantages:

  • Simple API for uploading files to a safe cloud storage.
  • Strong integration with your development environment and model objects.
  • Simple access to managed files through dynamic URLs.
  • Fast, optimized CDN delivery (correct cache settings, etc.)
Uploaded files are stored in the cloud and immediately made accessible. As opposed to uploaded images, raw files are kept as-is and not transformed in any way (though we have cool ideas for time-saving transformations we can offer for these files). 
 
Here's a quick example. Suppose you want to link to an Excel spreadsheet file from your website.
 
The following Ruby snippet will upload the XLS file to your Cloudinary account.
 
Cloudinary::Uploader.upload("sample_spreadsheet.xls", 
                                                   :public_id => "sample_spreadsheet",
                                                   :resource_type => :raw)
 
Behind the scenes, the uploading is done through our RESTful API. See our documentation for more details.
 
Downloading the uploaded file is done using a simple dynamic URL:


Cloudinary also supports a single API endpoint for all kinds of files, using the ‘auto’ resource type. This is useful if you allow your visitors to upload files of arbitrary format, image or otherwise, to your web app.
The result of the API upload request includes the final URL the uploaded file is available at. For image files, you can add any image transformation parameters as in standard image uploading.
 
The URL for uploading files with automatic type detection (replace ‘demo’ with your cloud name):
 
https://api.cloudinary.com/v1_1/demo/auto/upload

And in Ruby on Rails use the following:

Cloudinary::Uploader.upload(“sample_document.pdf”, :resource_type => :auto)

Like most of our features, raw file uploading is available now for all free & paid plans. 

 

Recent Blog Posts

Hipcamp Optimizes Images and Improves Page Load Times With Cloudinary

When creating a website that allows campers to discover great destinations, Hipcamp put a strong emphasis on featuring high-quality images that showcased the list of beautiful locations, regardless of whether users accessed the site on a desktop, tablet, or phone. Since 2015, Hipcamp has relied on Cloudinary’s image management solution to automate cropping and image optimization, enabling instant public delivery of photos, automatic tagging based on content recognition, and faster loading of webpages. In addition, Hipcamp was able to maintain the high standards it holds for the look and feel of its website.

Read more
New Image File Format: FUIF: Why Do We Need a New Image Format

In my last post, I introduced FUIF, a new, free, and universal image format I’ve created. In this post and other follow-up pieces, I will explain the why, what, and how of FUIF.

Even though JPEG is still the most widely-used image file format on the web, it has limitations, especially the subset of the format that has been implemented in browsers and that has, therefore, become the de facto standard. Because JPEG has a relatively verbose header, it cannot be used (at least not as is) for low-quality image placeholders (LQIP), for which you need a budget of a few hundred bytes. JPEG cannot encode alpha channels (transparency); it is restricted to 8 bits per channel; and its entropy coding is no longer state of the art. Also, JPEG is not fully “responsive by design.” There is no easy way to find a file’s truncation offsets and it is limited to a 1:8 downscale (the DC coefficients). If you want to use the same file for an 8K UHD display (7,680 pixels wide) and for a smart watch (320 pixels wide), 1:8 is not enough. And finally, JPEG does not work well with nonphotographic images and cannot do fully lossless compression.

Read more
 New Image File Format: FUIF:Lossy, Lossless, and Free

I've been working to create a new image format, which I'm calling FUIF, or Free Universal Image Format. That’s a rather pretentious name, I know. But I couldn’t call it the Free Lossy Image Format (FLIF) because that acronym is not available any more (see below) and FUIF can do lossless, too, so it wouldn’t be accurate either.

Read more