Visit Page
Skip to content

Putting the sRGB Back in WordPress

WordPress 3.x admin window showing duplicate images created for a blog post.

WordPress v3 works well and has attempted to think through everything. When it comes to images though a bit more is needed. WordPress automatically creates duplicate images at different sizes whenever you upload an image for a blog post. The idea behind this is great, it saves you the trouble of manually creating multiple sizes for thumbnails, feature images, post snippets, and the like. It also makes short work of linking everything; it’s all there done for you.

The problem lies in the fact that WordPress neglects to embed the color profile or the metadata in the duplicates. There’s not much you can do about the metadata (if that’s a concern then you should create your own image variations) but there is an easy way to re-embed the color profile associated with the original image file.

First off, what am I talking about and why do this? The web runs on sRGB when it comes to image files. sRGB is a background color space and is the lowest common denominator. Its gamut reflects the original CRT monitors and the bulk of the displays still in use (even LCD’s.) There are certain web browsers which are more color sophisticated (they display an image accurately if it has any embedded color profile) but there’s no guarantee that people are using them or that they have configured them properly. There are also differences in operating systems. Mac, despite of its reputation for graphics, assumes your monitor’s profile if none exists in an image file where Explorer assumes sRGB.

What all of the above means is that all bets are off when your images are viewed online and the only way to get accuracy and consistency is by having the correct color profile embedded in your image files.

1. Start off with an image in the sRGB color space and have that setting embedded in the image file. If you are converting from raw files then your raw convertor will allow you to select the color space of the processed file, if you are using Photoshop’s Save for Web there is a check-off box to convert to sRGB and embed it in the image file.

2. Go about your WordPress business as usual, make your blog post, upload your image files.

3. Go to your Mac OS Library (sorry this is Mac based info. only) and open the Scripts folder. Inside that open the ColorSync folder, and within that you will find the Embed script. Copy the Embed script to another location (e.g. your desktop and you can rename it if you like.)

4. Open your ftp client, navigate to your WordPress folder and open the Uploads folder (most likely blog/wp-content/uploads.) In Uploads go to the current year and month and in there you will find the image file(s) you just uploaded and the duplicates which WordPress created. Copy the duplicates to a folder on your desktop.

5. Open the duplicates folder, select all, and drag the files onto the Embed script. You will be prompted to select a color space, select sRGB. The sRGB profile has been reinserted into your files.

6. Upload the files back to where they came from in the WordPress Uploads folder on your server and you are done.

It sounds like more work than it is. It saves you having to open and re-save each file and it’s still less work then creating your own duplicate versions of files and having to manage and link them. It ensures that all of the duplicate images on your blog (thumbs; small, medium, & large versions) will look like the original you uploaded.

Since the question will come up – with color profiles there are always two options -> to assign or convert a color profile. In this case, by re-embedding the sRGB profile you are essentially assigning it. This is because it has been inadvertently left out, you are replacing what is missing.


  1. is there a solution in the next 3.1.2 WordPress Releases? I think its a bug when wordpress deletes the color profile of an resized image.

    • I consider it a bug too. Unfortunately most of the world is not aware or notices color management issues.

      I suspect that it would require that they change whatever they use to resize the images which would mean a bigger update than a 3.x.x.

Comments are closed.