I am currently working on a website and I have successfully installed my SSL certificate.

The GeoTrust SSL/TLS checker confirmed that the certificate chain (including CA) is properly installed. Everything looks fine on Chrome but my padlock is not green and on Firefox it actually states that the website is not secure because there is unencrypted elements on it.

I used an online service to check why that is and it turns out that indeed my images are not considered secure URLs. How do I deal with this situation, aka how do I embed images on my website securely?

5 Answers 5


Your image tags must currently look like:

<img src="http://example.com/images/image.jpg">

That http in there means that the image is NOT served securely. An attacker could change the image in transit and thereby change how your otherwise secure page looks to your users.

Instead you could use any of the following to serve the images securely:

  • Link to https explicitly: <img src="https://example.com/images/image.jpg">
  • Use relative linking to images on your own domain: <img src="/images/image.jpg">
  • Use protocol relative linking to use images from other domains: <img src="//example.com/images/image.jpg">

Explicit https will always serve the image securly (even when the page is not served securely) while relative linking will serve the image securely only if the page is served securely.

In Firefox and chrome you can click on the padlock and get more information about the problem. Having done so, here is a screen shot from Firefox showing a list of all the images an the page. It is easy to scan the list and see which ones are http:

  • 3
    "An attacker could change the image in transit and thereby change how your otherwise secure page looks to your users." - or even trigger a vulnerability in the renderer. Commented Dec 17, 2015 at 7:05
  • 3
    And hijack cookies, which might include access tokens.
    – Darkhogg
    Commented Dec 17, 2015 at 12:56
  • It sounds very much like it is adviced to do so. Thanks to you I have managed to get my green padlock but a friend said that encrypting images might slow down the page. Is this an issue in my case?
    – mti_
    Commented Dec 17, 2015 at 14:26
  • 4
    There is certainly some overhead to encryption, however it is usually no more than 10% these days. That performance penalty (even for images) is the price you have to pay for a secure site. Commented Dec 17, 2015 at 14:27
  • whynopadlock.com is a handy tool to quickly pinpoint the unsecure resources at a specific URL.
    – Ville
    Commented Dec 17, 2015 at 19:13

The issue is that your page is serving links from a http location as opposed to https. This is due to using absolute http links to reference resources such as images. There are two better methods which will enable you to reference links in either http or https and avoid this issue.

It requires you to find these links and change them either to:

  1. relative links: ie. /wp-content/yourtheme/images/image1.jpg
  2. or place // at the front of the domain as in //example.com/wp-content/wp-content/yourtheme/images/image1.jpg This will then serve these resources over http or https based on whichever request was made.

In both Chrome and Firefox you can click the padlock icon and then click through to view a list of the offending insecure links. And if you cannot see any images or other resources highlighted in the browser but are still getting errors you may discover that there is a javascript call that is referencing links absolutely via http.

  • 2
    // at the beginning is nōn-standard, and browsers such as Lynx will complain.
    – mirabilos
    Commented Dec 17, 2015 at 14:42
  • 2
    @mirabilos RFC 1808 is the standard for URLs and specifies protocol relative links (starting with //) in section 2.4.3. The standard is now 15 years old and implemented by all major browsers including Lynx Commented Dec 17, 2015 at 19:20
  • #mirabilos Check your recommended Google repository links. You'll find Google has been using them for many years.
    – garth
    Commented Dec 18, 2015 at 2:08

It is really basic. When you are building websites served over SSL (https) any reference in your code that is not prefaced with https will throw up security warnings - other than links. Note that most (all) browsers also default relative links to http. So if you would reference /uploads/12/5/img.jpg or /js/jquery.js the transfer protocol will default to http - which is really annoying.

All browsers handle the warnings a little different but you will get some kind of message. A general statement would be that the new the browser the more severe the message will be. Some older browsers practically ignore these errors while newer browsers can act like your world is under attack because of the missing "s".

  • 11
    "most (all) browsers also default relative links to http" Err, what? Absolutely all browsers, unless they're broken, would use current protocol if you not specify new one explicitly. Commented Dec 17, 2015 at 10:28
  • 5
    Oleg is right; that's not "annoying": it's completely wrong. Commented Dec 17, 2015 at 12:06
  • 3
    This is completely wrong. Disregard this answer.
    – martijnve
    Commented Dec 17, 2015 at 13:05
  • @martijnve - How is my answer wrong?
    – blankip
    Commented Dec 17, 2015 at 14:57
  • 4
    @blankip see oleg V. Volkovs comment. Any reference that does include http is wrong. ALL others are fine. (protocol relative, domain relative, path relative). And you should use relative links in almost all cases anyway.
    – martijnve
    Commented Dec 17, 2015 at 15:13

If none of these suggestions help when it comes to inability to display images after you have enabled SSL on your webpage, then check just in case cPanel's settings for Hotlinks, which is under the Security section of the cPanel. It's very possible that in this setting you have the following: http://example.com and http://www.example.com are enabled to allow to access the images while the https version of these are not enabled.


Check your secure url protocol configuration in your cms/wordpress/magento or any other platform you're using. You can also share some of your image tags, but basic img src images don't give that kind of errors.

Image tag structure is important, but the focus of your question I think its relative to the SSL Certificate "type" installed on your site. A personal case happened to me with a "Standard GoDaddy SSL Certificate.

You´ll see a warning icon in Firefox (specifically) url search bar, saying that there might be insecure images or elements on your site. As far as I know its just a matter of how firefox processes info about the certificate, or the info included in it. This doesn't happens in safari, chrome or other browsers. I found a solution for this, installing instead of a "Standard SSL" a "Premium SSL Certificate or EVC extended validation certificate" which has more detailed info about the sites company. You'll get a green padlock secure url bar.

However premium ssl certificate could be a bit more expensive, around $150-$200 USD a year.

enter image description here

  • 5
    This is not true because: 1) <img src="..."> tags can indeed give this kind of error, if you enter an HTTP url (as opposed to an HTTPS url) and 2) the type of ceritificate or the way it is processed have absolutely nothing to do with this
    – elaforma
    Commented Dec 16, 2015 at 19:48
  • I use for img src global media tags like {{media url="path/to/image.jpg"}} with or without ssl protocol and I get no errors. By the way im pointing to Stephen´s Firefox ssl error displayed. Regards.
    – Fercho
    Commented Dec 16, 2015 at 20:16
  • 3
    If you use relative URLs, there are no problems, because they are relative. Please read the other answer. I know that you are referring to Stephen's error. Certificate types still do't have anything to do with it.
    – elaforma
    Commented Dec 16, 2015 at 20:42
  • The type of certificate has no impact on the so-called 'mixed-content warning'. Also, all modern browsers these days show the warning, some clearly, others simply by refusing to show the Lock icon. Commented Dec 17, 2015 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.