Why does my browser say my SSL page is only "partially secure"?
The first step to making your pages display as “secure” is adding a free SSL certificate, then accessing your site using https:// at the beginning (with an extra “s”).
Each Web browser handles this situation differently. Some browsers may ask if you want to display the nonsecure items, for example. Others may tell you that that the page is only “partially secure”, or is “not fully secure”. In many cases, the “padlock icon” in the browser may not fully activate, or the word “Secure” may not appear in the address bar.
To prevent this from happening, make sure that none of the page’s included URLs begin with http://, such as src="http://. You can replace such URLs with src="https://, or use URLs that don’t include any hostname.
On this page:
- Fixing this in WordPress
- An example of the problem
- Finding the problem in detail
- Using protocol-relative URLs
Fixing this in WordPress
If your site is a WordPress site, you can sometimes fix this by logging in to the WordPress dashboard, clicking Settings > General, and changing both the “WordPress Address (URL)” and “Site Address (URL)” so that they begin with https:// (that is, add an s after “http” and before the colon).
This will force WordPress to use your SSL certificate for most resources it tries to load.
If that doesn’t help, or if you don’t use WordPress, you’ll have to track down the exact problem using the tips below.
An example of the problem
Imagine your page is at this ”https“ address:
<link rel="stylesheet" href="http://www.example.com/style.css"> <img src="http://www.example.com/image.jpeg"> <script src="http://www.third-party-site.com/script.js">
To fix this for items included from your own site, you can remove the hostname from the URLs. That way, the visitor’s browser will automatically use SSL to load the included items when the enclosing page is loaded as SSL:
<link rel="stylesheet" href="/style.css"> <img src="/image.jpeg">
But that trick won’t work if your HTML code references content on a third-party site: you’d need to change that one to something like:
This will only work if the third-party site allows SSL, though. If they don’t, there's no way to fix it.
In a pinch, some people just force all included URLs to always be loaded as SSL, although this will slow down your site for visitors who don’t load the enclosing page as SSL:
<link rel="stylesheet" href="https://www.example.com/style.css"> <img src="https://www.example.com/image.jpeg"> <script src="https://www.third-party-site.com/script.js">
Finding the problem in detail
The easiest way to find exactly what’s wrong with a given page is usually to use the third-party Why No Padlock? site. It can often tell you exactly what’s wrong.
If you want more details, many Web browsers will show you the source of the problem if you view the page in question, then open a special window:
- In Google Chrome, choose More Tools > Developer Tools, then look at the “Console” tab
- In Mozilla Firefox, choose Tools > Web Developer > Web Console, then reload the page
- In Safari, enable the Develop menu and choose Show Error Console
These windows will usually tell you something like “The page at https://www.example.com/ ran insecure content from http://www.example.com/style.css.”
Using protocol-relative URLs
There's one more way you can solve this problem. You can specify the URLs using what is known as “protocol-relative URL”. In this format, you omit the leading http: or https: from the URL. So in the case of the example above, the links would become:
<link rel="stylesheet" href="//www.example.com/style.css"> <img src="//www.example.com/image.jpeg">
When using this format, resources will be loaded via http: if the current page was loaded via http:, or will be loaded via https: if the current page was loaded via https:. Another benefit of this format is that it can solve the problem of properly referring to URLs on third-party sites.
This format is a relatively new development. While we can’t guarantee that all browsers support it, it seems that most of the commonly-used browsers do. As always, be sure to test your site with the browsers likely to be used by your target audience.