What Is HTTPS? How SSL Secures Your Website

HTTPS stands for HyperText Transfer Protocol Secure. It is the encrypted version of HTTP, the protocol your browser uses to communicate with web servers. When you visit a website with https:// in the URL, the connection between your browser and the server is encrypted using SSL/TLS, which prevents anyone from reading or modifying the data in transit.

Every modern website should use HTTPS. Browsers mark HTTP sites as "Not secure," search engines prefer HTTPS pages, and many web features only work over secure connections. This guide explains what HTTPS does, how the encryption works, and what it takes to enable it. For the details of the encryption protocols, see SSL vs TLS.

HTTP vs HTTPS

HTTP (HyperText Transfer Protocol) transmits data in plain text. Every piece of information sent between the browser and the server -- URLs, form data, cookies, page content -- can be read by anyone who can observe the network traffic. This includes your ISP, anyone on the same Wi-Fi network, and any device routing your traffic between you and the server.

HTTPS adds a layer of encryption (SSL/TLS) between HTTP and the network. The same HTTP messages are transmitted, but they are encrypted before being sent and decrypted on arrival. An observer sees only encrypted ciphertext.

The practical differences:

| Feature | HTTP | HTTPS | |---|---|---| | URL prefix | http:// | https:// | | Default port | 80 | 443 | | Encryption | None | TLS encryption | | Browser indicator | "Not secure" warning | Padlock icon | | Data visibility | Readable by network observers | Encrypted | | SEO impact | No ranking boost | Minor ranking signal | | Modern API access | Blocked by many APIs | Full access |

How HTTPS Works

When you navigate to an HTTPS URL, your browser and the web server perform a TLS handshake before any data is exchanged. This handshake establishes an encrypted channel.

The TLS Handshake (Simplified)

1. Client Hello. Your browser contacts the server and sends a list of supported TLS versions and cipher suites (encryption algorithms).

2. Server Hello. The server selects a TLS version and cipher suite from the browser's list and sends its SSL certificate.

3. Certificate verification. The browser checks that the certificate is valid: issued by a trusted certificate authority, not expired, not revoked, and issued for the correct domain. If any check fails, the browser shows a security warning.

4. Key exchange. The browser and server agree on a shared secret (session key) using asymmetric encryption. The server's certificate contains a public key that the browser uses to encrypt the initial key exchange. Once both sides have the session key, they switch to symmetric encryption, which is faster.

5. Secure connection established. All subsequent HTTP traffic is encrypted with the session key. The browser shows the padlock icon.

This process takes tens of milliseconds. With TLS 1.3 (the current standard), the handshake requires only one round trip, and with session resumption, it can be zero round trips for returning visitors.

What HTTPS Protects

Confidentiality. The content of every request and response is encrypted. Page content, form submissions, cookies, headers, and even the specific URLs visited within a domain are hidden from network observers.

Integrity. HTTPS detects if data is modified in transit. If an attacker attempts to alter the content (injecting ads, modifying download links, changing form actions), the modification is detected and the connection is terminated.

Authentication. The SSL certificate proves the server's identity. This prevents an attacker from impersonating a website by positioning themselves between you and the real server (a man-in-the-middle attack).

What HTTPS Does Not Protect

HTTPS encrypts the connection, not the website. A few things remain visible or unprotected:

The domain you are visiting. DNS queries (the lookup that translates example.com to an IP address) are typically unencrypted, revealing which domain you are visiting. DNS over HTTPS (DoH) addresses this, but it is not universal.

The fact that you are connected. Network observers can see that you have a connection to a specific IP address, even if they cannot read the content.

Data at rest on the server. HTTPS protects data in transit. Once your data reaches the server, how it is stored and protected is a separate concern.

Phishing. A phishing site can have a valid HTTPS certificate. The padlock icon means the connection is encrypted, not that the website is legitimate or trustworthy.

Why HTTPS Is Required

Browser Warnings

Since July 2018, Chrome displays a "Not secure" label in the address bar for all HTTP pages. Firefox, Safari, and Edge show similar indicators. For pages with form fields (login, search, contact forms), the warnings are more prominent.

These warnings significantly affect user behavior. Studies have shown that security warnings reduce form completion rates and increase bounce rates.

SEO

Google confirmed HTTPS as a ranking signal in 2014. While it is described as a lightweight signal, it is a tiebreaker: between two otherwise equal pages, the HTTPS version ranks higher. Google Search Console also reports HTTPS-specific issues and encourages migration.

Browser Feature Requirements

Many modern browser APIs require a secure context (HTTPS):

• Service Workers: Required for Progressive Web Apps, offline functionality, and push notifications.
• Geolocation API: Browsers block location access on HTTP pages.
• Web Bluetooth and Web USB: Security-sensitive hardware APIs require HTTPS.
• Clipboard API: Writing to the clipboard requires a secure context.
• HTTP/2: While the protocol specification does not require HTTPS, all major browsers only support HTTP/2 over encrypted connections. HTTP/2 significantly improves page load performance.

Compliance

PCI DSS requires encryption for any page that processes payment information. GDPR requires appropriate technical measures to protect personal data, and encryption in transit is a baseline expectation. HIPAA requires encryption for protected health information. Most compliance frameworks treat HTTPS as a minimum requirement.

Enabling HTTPS on Your Website

Get an SSL Certificate

You need an SSL certificate for your domain. Options include:

• Let's Encrypt: Free, automated DV certificates. Supported by most hosting providers. See Free SSL Certificates Guide.
• Your hosting provider: Many providers include free or paid SSL certificates.
• Commercial CAs: DigiCert, Sectigo, GlobalSign, and others offer paid certificates with OV and EV validation.

For the full process, see How to Get an SSL Certificate.

Install the Certificate

Install the SSL certificate on your web server. The process varies by server software. See How to Install SSL.

Redirect HTTP to HTTPS

After enabling HTTPS, set up a redirect from HTTP to HTTPS so that visitors who access http://example.com are automatically sent to https://example.com. This is done with a 301 redirect at the server level.

For detailed instructions, see the HTTP to HTTPS Redirect Guide on Redirect Tracer.

Update Internal Links

Change all internal links, image sources, script references, and stylesheet links from http:// to https:// (or use protocol-relative URLs). Mixed content (HTTPS page loading HTTP resources) triggers browser warnings and can block resources from loading.

Set Up HSTS

HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for your domain, even if the user types http://. This prevents downgrade attacks where an attacker intercepts the initial HTTP request before the redirect to HTTPS.

Add the HSTS header to your server responses:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HTTPS Performance

A common concern about HTTPS is performance. The TLS handshake adds latency, and encryption/decryption consume CPU resources. In practice, the impact is negligible on modern hardware and with modern protocols.

TLS 1.3 handshake: One round trip for new connections, zero round trips for resumed connections. The handshake adds 10-50ms for new connections.

Encryption overhead: Modern processors include hardware acceleration for AES encryption (AES-NI instructions). The CPU overhead of encrypting and decrypting HTTPS traffic is typically less than 1% on a modern server.

HTTP/2 benefits: Since browsers only support HTTP/2 over HTTPS, enabling HTTPS unlocks HTTP/2's performance improvements: multiplexing (multiple requests over a single connection), header compression, and server push. For most websites, the HTTP/2 performance gains more than offset the TLS handshake overhead.

Verifying HTTPS

After enabling HTTPS, verify that everything is working correctly:

Check the certificate. Use an SSL checker or the browser's certificate viewer to confirm the certificate is valid, not expired, and covers the correct domain names.

Check for mixed content. Open the browser's developer console (F12) and look for mixed content warnings. These indicate that the HTTPS page is loading resources over HTTP.

Test the redirect. Verify that http://example.com redirects to https://example.com with a 301 status code. Use Redirect Tracer to check the full redirect chain.

Verify HSTS. Check that the Strict-Transport-Security header is present in your server's responses.

For detailed verification steps, see How to Check SSL Certificate and How to Check SSL in Browser.

References

1. RFC 9110, "HTTP Semantics," June 2022. https://httpwg.org/specs/rfc9110.html
2. RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3," August 2018. https://datatracker.ietf.org/doc/html/rfc8446
3. Google Security Blog, "A secure web is here to stay," February 2018. https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
4. Google, "HTTPS as a ranking signal," August 2014. https://developers.google.com/search/blog/2014/08/https-as-ranking-signal