Cloudinary Blog

I’ve spent a lot of time thinking about the rules of putting images on the web.

For such a flexible medium as the web, software development can feel like a painstaking, rules-oriented game—an errant comma might break a build, a missing semicolon might wipe out an entire page. For a long time, the laws of image rendering seemed similarly cut-and-dry: For example, if your markups contained an img element , the singular content of its src attribute would be foisted on the audience regardless of their browsing context, period.

Consumers today expect media-rich experiences. No longer a novelty, it’s second nature to swipe through multiple photos on mobile apps, zoom in on product images for a closer look, visualize online travel reviews, socialize cool video clips while browsing, and encounter brand messages when walking into brick-and-mortar stores. These experiences weave together visual cues and clues with relevant content to create meaning and more authentic connections for customers.

Recently we added the Cloudinary Demo - eCommerce App to the Google Play Store. This app demonstrates the best practices for optimal delivery of images on a storefront, including category pages, product pages, and a shopping cart. At the time, we published Introducing the Cloudinary Demo Android App, Part 1, which provided an under-the-hood tour of how the eCommerce Android App was designed and how Cloudinary was integrated throughout.

When you visit a website—whether from your laptop, phone, or tablet—you expect the pages to load fast and all the images to look great. However, ensuring that websites live up to visitor expectations can be more complicated than it might seem.

Last month we unveiled a refresh of our website. As with all redesigns, there were numerous drivers behind the rollout. First and foremost, we’re a company that understands the power of visual storytelling, and the ways in which a website must beautifully and clearly convey a brand’s story and offerings. Our website needed to better reflect our brand and our solutions. This post highlights some of the thinking behind our changes.

One main reason people use Cloudinary is to leverage its capabilities for transforming digital assets, such as images and videos. Whether for optimization or aesthetics, it’s easy and fast to transform digital media for your web or mobile projects.

Part 1 of this series introduces the Free Lossy Image Format (FUIF), which I recently developed. Part 2 explains the why, what, and how of FUIF. This post, part 3 of the series, delves into how FUIF is legacy friendly, which I alluded to in Part 2.

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.

Look around any software company and you're almost bound to see developers, headphones on, coding away to their favorite tunes. For most developers, music plays an important role in their lives: from listening to it while they work to attending concerts or major music festivals, like Coachella and South by Southwest Music Festival (SXSW).

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.