Knowing how to check if HTTPS is forced helps you confirm that visitors are always routed to a secure connection, not just when they type it manually.
The details matter because a site can appear secure in the browser while still allowing insecure HTTP access in edge cases.
What it means when HTTPS is forced
HTTPS is considered forced when every request to the non-secure http:// version is automatically upgraded or redirected to https://.
In practice, this can happen through server redirects, application rules, Content Security Policy directives, or HTTP Strict Transport Security (HSTS).
For site owners, forcing HTTPS protects login pages, forms, cookies, and session data.
For SEO, it also reduces duplicate URL issues and helps search engines consistently index the secure version of the site.
Check the redirect behavior in a browser
The simplest way to start is by typing the plain HTTP version of your site into a browser address bar.
If the browser immediately changes the URL to HTTPS, that is a strong sign that redirect logic is in place.
Use several pages, not just the homepage.
Test a few common paths such as:
http://example.com/http://example.com/abouthttp://example.com/contacthttp://www.example.com/
If all of these switch to HTTPS, the site is likely forcing secure connections at the application or server level.
If some pages remain accessible over HTTP, the implementation is incomplete.
Inspect the response with a command-line tool
Browser behavior can hide details, so use a tool such as curl to inspect the actual HTTP response.
This is one of the most reliable ways to check if HTTPS is forced.
curl -I http://example.comLook for a redirect status code such as 301, 302, 307, or 308, and check whether the Location header points to the HTTPS version.
HTTP/1.1 301 Moved Permanently
Location: https://example.com/You can also test a specific URL path to see whether each route is handled correctly:
curl -I http://example.com/loginIf the response returns 200 OK over HTTP without redirecting, HTTPS is not fully forced for that path.
Check for HSTS headers
HSTS, or HTTP Strict Transport Security, is a browser policy that tells supported browsers to only use HTTPS for a site during a defined time window.
If HSTS is configured, it is a strong indicator that HTTPS is being actively enforced.
To verify HSTS, inspect the response headers for Strict-Transport-Security.
You can do this with browser developer tools, curl, or online header checkers.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadImportant details to look for include:
- max-age: how long browsers should remember the policy
- includeSubDomains: whether subdomains are also forced to HTTPS
- preload: whether the site may be eligible for browser preload lists
HSTS does not replace redirects for first-time visitors, because browsers need to learn the policy before they can apply it.
That is why a site should still redirect HTTP to HTTPS at the server level.
Use browser developer tools to verify the network path
Modern browser developer tools make it easy to confirm whether a request is redirected or loaded directly over HTTPS.
Open the Network tab, load the HTTP URL, and inspect the request chain.
Check for these signs:
- A 301 or 308 response from HTTP to HTTPS
- Multiple hops, such as HTTP to www to HTTPS
- Mixed content warnings if page assets still load over HTTP
If the first request is made to HTTP and then upgraded, that is normal for a forced-HTTPS setup.
If the browser loads a page over HTTP without redirection, the configuration is incomplete or missing.
Test with and without www
Many sites force HTTPS but only on one hostname.
For example, example.com may redirect correctly while www.example.com does not, or the reverse may be true.
To avoid false confidence, test all common hostname combinations:
http://example.comhttp://www.example.comhttps://example.comhttps://www.example.com
A fully enforced setup should normalize both scheme and hostname in a predictable way.
Common patterns include redirecting all traffic to either the canonical www or non-www HTTPS version.
Review server and platform settings
Whether HTTPS is forced often depends on the platform behind the site.
Common places to check include:
- Apache:
.htaccessor virtual host rules - Nginx: server blocks and rewrite rules
- Cloudflare: SSL/TLS mode and Always Use HTTPS
- WordPress: site URL settings, plugins, and .htaccess redirects
- Load balancers: edge redirects and TLS termination configuration
If you manage the server, confirm that redirects are applied before application logic.
If redirects are only handled in JavaScript or inside a page template, they are weaker and less reliable than server-side enforcement.
Look for mixed content as a clue
Even if the page itself forces HTTPS, insecure assets can reveal gaps in implementation.
Mixed content happens when an HTTPS page loads images, scripts, stylesheets, or fonts from HTTP URLs.
Open the browser console and look for warnings such as blocked insecure resources.
Mixed content does not mean the main page is accessible over HTTP, but it does indicate that the site is not fully hardened.
A site that truly forces HTTPS should also reference secure asset URLs or protocol-relative equivalents where appropriate.
Confirm canonical URLs and internal links
Search engine signals should also point to HTTPS if the site is forcing it correctly.
Review the page source or rendered HTML for canonical tags and internal links.
Look for:
<link rel=