How Does HTTPS Work?

HTTPS works by using Transport Layer Security (TLS) to encrypt communication between a web browser and a server. Before exchanging protected webpage content, the browser and server establish a secure connection, authenticate the server, and create shared encryption keys. Those keys protect HTTP requests and responses while they travel across the network.

This prevents someone monitoring the connection from easily reading sensitive information, such as passwords, form submissions, or private messages. TLS also helps detect attempts to modify the protected data in transit.

However, HTTPS does not make a website automatically trustworthy or hide every detail of your internet activity. Its primary purpose is to protect communication between the endpoints of an encrypted connection.

What Is HTTPS?

HTTPS stands for Hypertext Transfer Protocol Secure.

It is the secure form of HTTP, the protocol browsers and web servers use to exchange web resources.

The important difference is that HTTPS protects HTTP communication with TLS encryption and authentication.

For example, consider these two addresses:

http://example.com

https://example.com

Both use HTTP semantics to request web resources, but the second uses a secure connection.

With ordinary HTTP, an attacker positioned along an unprotected network path may be able to observe or modify transmitted content.

With properly configured HTTPS, the HTTP messages are protected by cryptographic mechanisms that provide confidentiality, integrity, and server authentication.

According to MDN’s HTTPS explanation, HTTPS uses TLS to encrypt communication between clients and servers.

HTTPS is now the standard way to deliver websites, online applications, and services that exchange information over the web.

It is particularly important when transmitting login credentials, payment information, personal details, and other sensitive data.

How Does HTTPS Work Step by Step?

To understand HTTPS, imagine opening an online store through your browser.

You enter:

https://shop.example.com

Several processes happen before the browser can securely exchange the website’s content.

Step 1: The Browser Identifies the HTTPS Address

When you enter a website address, the web browser interprets its URL.

The https:// scheme tells the browser that the requested resource must be accessed through a secure HTTP connection.

The browser also identifies the hostname:

shop.example.com

That hostname is important for locating the server and verifying its identity.

A domain name provides the human-readable name associated with the website.

Before the browser communicates with the destination, it generally needs suitable network addressing information.

Step 2: DNS Helps Locate the Server

The browser or operating system uses the Domain Name System (DNS) to obtain information associated with the website’s hostname.

DNS can return an IPv4 or IPv6 address that the browser can use to contact the service.

The answer may come from a cache or require additional queries through the DNS hierarchy.

This lookup is separate from HTTPS encryption.

A traditional DNS query is not automatically protected simply because the website being visited uses HTTPS.

Some devices and browsers use encrypted DNS transports, such as DNS over HTTPS, which protect DNS queries between the client and the selected resolver.

Once the browser has the required destination information, it can begin establishing communication.

Step 3: The Browser Establishes a Transport Connection

The next stage depends on the HTTP version and transport protocol being used.

For HTTPS using HTTP/1.1 or HTTP/2, the browser typically establishes a TCP connection before negotiating TLS.

TCP provides reliable, ordered data delivery between the communicating endpoints.

HTTP/3 uses a different approach.

Instead of TCP, HTTP/3 operates over QUIC, which uses UDP and incorporates TLS 1.3 security mechanisms into its transport handshake.

The HTTP/3 specification, RFC 9114, defines how HTTP communication operates over QUIC.

The important point is that HTTPS is not restricted to TCP.

Different versions of HTTP can use different transport mechanisms while still protecting web communication.

Step 4: The Browser Begins the TLS Handshake

For a conventional TLS 1.3 connection over TCP, the browser begins a process called the TLS handshake.

The handshake allows the browser and server to agree on the cryptographic parameters needed for protected communication.

The browser sends a message called ClientHello.

This message can include information such as:

• Supported TLS versions.
• Supported cryptographic algorithms.
• A random value used during the handshake.
• Cryptographic key-exchange information.
• Extensions describing supported connection capabilities.

The server examines the information and responds with a ServerHello.

The response selects compatible cryptographic parameters and provides the server’s contribution to the key-establishment process.

The TLS 1.3 specification, RFC 8446, defines these messages and the associated security mechanisms.

TLS does not normally begin by sending the browser’s password or website contents.

First, the two endpoints must establish the cryptographic conditions required to protect subsequent application data.

Step 5: The Server Presents Its Digital Certificate

The browser also needs to verify that it is communicating with the intended server.

This is where the server’s TLS certificate becomes important.

A TLS certificate contains information connecting a public key to one or more identities, commonly DNS names.

For a typical website, the browser checks that the certificate is appropriate for the hostname being visited.

It also checks whether the certificate chains to a trusted certificate authority, whether it is valid for the relevant time, and whether other applicable validation requirements are satisfied.

A certificate authority (CA) is an organization trusted to issue certificates under defined verification and operational rules.

For example, Let’s Encrypt explains how its automated certificate issuance process validates domain control before issuing a certificate.

The browser relies on its configured trust system to evaluate the certificate and the server’s proof of possession of the corresponding private key.

This authentication is essential.

Without it, encryption alone could establish a protected connection to an attacker pretending to be the intended website.

Step 6: The Browser and Server Establish Shared Encryption Keys

After negotiating the connection parameters, the browser and server derive cryptographic keys for protecting their communication.

This process uses cryptographic key-establishment mechanisms rather than sending an ordinary shared password across the network.

In a typical full TLS 1.3 handshake, ephemeral Diffie-Hellman key exchange allows the endpoints to derive shared secrets without transmitting those secrets directly.

The resulting key material is used to derive keys for protecting the connection.

This combines two important approaches to cryptography.

Public-key cryptography helps establish and authenticate the connection.

Symmetric encryption protects the application data exchanged after the secure connection has been established.

Symmetric encryption is well suited to handling ongoing communication efficiently.

A common misunderstanding is that every webpage and image is encrypted directly using the certificate’s public key.

That is not how modern TLS normally protects application data.

Instead, the handshake establishes suitable shared secrets, from which the endpoints derive symmetric traffic keys.

Step 7: HTTPS Encrypts the HTTP Request

Once the secure connection is established, the browser can send its HTTP request through the protected channel.

For example, the application-level request may conceptually contain:

GET /account HTTP/1.1
Host: shop.example.com

The exact on-the-wire representation depends on the HTTP version.

TLS protects the HTTP communication before it travels across the network.

An observer on an intermediate network cannot simply read the protected request as ordinary text.

The URL path, relevant HTTP headers, cookies, and request body are protected within the encrypted HTTP exchange.

However, the underlying network still needs certain routing information, such as destination IP addresses, to deliver packets.

HTTPS therefore encrypts application communication without making all associated network metadata disappear.

Step 8: The Server Decrypts and Processes the Request

When the encrypted information reaches the TLS endpoint, the receiving system uses the established keys to authenticate and decrypt the protected records.

The recovered HTTP request can then be processed.

The server or application may retrieve an HTML document, execute code, access a database, or perform another authorized operation.

The HTTP request-and-response model defines how clients request resources and servers return responses.

The server prepares the result, and the secure connection protects the response during transmission.

For example, the response may contain account information, an HTML document, images, or application data.

Step 9: The Browser Decrypts the Response

The encrypted response travels back across the network.

When the browser receives it, the TLS implementation checks the protection applied to the incoming data and decrypts the response using the appropriate traffic keys.

The browser then processes the recovered HTTP content.

It may parse HTML, download additional resources, apply CSS, execute JavaScript, and render the page.

Additional HTTPS requests may be required for images, scripts, fonts, or application data.

The user sees the finished website, while the underlying communication remains protected according to the connection’s TLS configuration.

This broader process is part of how the internet works.

What Does HTTPS Actually Protect?

HTTPS provides three central security properties.

Security Property	What It Does	Example
Confidentiality	Protects the content of communication from unauthorized network observers	Helps prevent someone on the network from reading a submitted password
Integrity	Helps detect unauthorized changes to protected information	Prevents unnoticed modification of an encrypted HTTP response in transit
Authentication	Helps verify the identity of the server endpoint	Allows the browser to check that the certificate matches the requested hostname

These protections work together.

Encryption without authentication could protect a connection to the wrong server.

Authentication without encryption would not prevent others from reading transmitted information.

Integrity protection helps ensure that received data has not been secretly altered while traveling through an untrusted network.

As the MDN TLS security guide explains, TLS combines encryption, integrity protection, and authentication to secure communication.

However, these properties describe protection for a connection, not the trustworthiness of the website’s business or its stored data.

How Does HTTPS Encryption Work?

HTTPS encryption is based on cryptographic algorithms and keys.

A cryptographic key is information used by an algorithm to encrypt, decrypt, or authenticate data.

Modern TLS uses several cryptographic techniques for different purposes.

Public-Key Cryptography

Public-key cryptography uses a mathematically related pair of keys.

One key is public and can be distributed to others.

The other is private and must remain protected.

In TLS, public-key cryptography helps authenticate the server and establish shared secrets.

For example, the server can prove possession of a private key corresponding to the public key associated with its certificate.

The browser can verify that proof using the relevant cryptographic information.

Symmetric Encryption

Symmetric encryption uses secret key material shared by the communicating endpoints.

Once the TLS handshake has established the necessary keys, symmetric cryptographic algorithms protect the application data.

Modern TLS commonly uses authenticated encryption algorithms.

These algorithms provide both confidentiality and integrity protection.

Examples of supported authenticated encryption constructions in TLS 1.3 include AES-GCM and ChaCha20-Poly1305.

The specific algorithm depends on negotiation and implementation support.

Why Does TLS Use Both Approaches?

Public-key operations are useful for establishing trust and shared secrets between systems that have not previously exchanged a private communication key.

Symmetric cryptography is efficient for protecting the ongoing exchange of data.

TLS combines these capabilities so that browsers and servers can establish secure connections without requiring users to manually share encryption keys.

What Is Forward Secrecy?

Forward secrecy is a security property associated with certain key-establishment methods.

In typical full TLS 1.3 handshakes using ephemeral Diffie-Hellman, the session keys are derived from temporary key-exchange secrets.

This helps protect previously recorded communication even if the server’s long-term authentication private key is compromised later.

However, not every resumed or early-data connection has identical security properties.

For example, TLS 1.3 permits early data in certain resumed connections, and that early data has different forward-secrecy and replay-related limitations.

These distinctions are described in RFC 8446.

What Is the Difference Between HTTP and HTTPS?

HTTP and HTTPS use the same basic model for exchanging web requests and responses.

The difference is how the communication is protected.

Feature	HTTP	HTTPS
Full name	Hypertext Transfer Protocol	Hypertext Transfer Protocol Secure
Transport protection	No inherent TLS protection	Protected using TLS
Confidentiality	Not provided by HTTP alone	Provided for protected connection contents
Integrity against network tampering	Not cryptographically guaranteed by HTTP alone	Protected by TLS
Server authentication	Not provided by HTTP alone	Uses TLS authentication
Typical URL scheme	http://	https://
Conventional default port	80	443
Suitable for sensitive web communication	No, without additional protection	Yes, when correctly configured

A more detailed discussion of HTTP requests, responses, methods, headers, and status codes belongs in How Does HTTP Work?.

One important distinction is that HTTP and HTTPS are not separate kinds of website content.

Both can deliver HTML, JSON, images, and other resources.

HTTPS adds transport security around HTTP communication.

The port numbers shown above are defaults, not absolute requirements for every deployment.

For HTTP/3, HTTPS communication commonly uses QUIC over UDP, typically on port 443.

How Does an SSL Certificate Work with HTTPS?

People often refer to website TLS certificates as SSL certificates.

SSL stands for Secure Sockets Layer, an older predecessor of TLS.

Modern HTTPS uses TLS rather than the obsolete SSL protocol versions.

The term SSL certificate remains common in hosting and website administration, but TLS certificate is technically more accurate.

What Does a TLS Certificate Contain?

A typical certificate includes information such as:

• The public key associated with the certificate.
• The DNS names or other identities covered by the certificate.
• The certificate issuer.
• A period of validity.
• A digital signature from the issuing certificate authority.

A certificate helps the browser determine whether the server can be authenticated for the requested hostname.

It does not contain the server’s private key.

That private key must remain protected.

How Does a Certificate Authority Verify a Domain?

For domain-validated certificates, the certificate authority verifies that the applicant demonstrates control over the relevant domain.

This can involve answering a challenge through DNS or a specified website resource.

For example, an automated certificate issuance system may ask the domain operator to create a particular DNS record.

The CA verifies the challenge before authorizing certificate issuance.

Let’s Encrypt’s ACME certificate issuance process describes this type of domain-control validation.

This verification does not establish that the website operator is honest, reputable, or authorized to sell a particular product.

It establishes control of the domain under the certificate authority’s validation rules.

Does HTTPS Hide Your Browsing Activity from Your ISP?

HTTPS protects the contents of the encrypted web exchange, but it does not provide complete anonymity.

Your internet service provider still operates part of the network carrying your traffic.

Certain information remains visible because packets must be routed between networks.

For example, depending on the connection and configuration, an ISP or another network observer may be able to see:

• Destination IP addresses.
• Connection timing and duration.
• Approximate amounts of data transferred.
• Unencrypted DNS queries, if traditional DNS is used.
• Some hostname information exposed during connection setup.

However, properly protected HTTPS traffic prevents an ordinary network observer from reading encrypted HTTP paths, form contents, messages, or cookies simply by inspecting packets.

Can an ISP See the Entire URL?

Generally, not when the HTTP request is protected by HTTPS.

Consider:

https://shop.example.com/account/orders?id=123

The HTTPS connection protects the HTTP request target, including the path and query string.

The network still needs addressing information to deliver the traffic.

Additional hostname information may be exposed by DNS or TLS connection metadata, depending on the technologies used.

Some modern deployments use Encrypted ClientHello (ECH) and encrypted DNS to reduce the amount of hostname information visible to intermediaries.

Support and effectiveness depend on the client, resolver, server, and network configuration.

The key distinction is that HTTPS protects webpage communication but does not necessarily conceal the fact that your device communicated with a particular network endpoint.

Does HTTPS Protect You on Public Wi-Fi?

Yes, properly configured HTTPS helps protect web communication even when the underlying Wi-Fi network is not trusted.

For example, imagine using an unsecured wireless network at an airport.

Other devices may share portions of the same network infrastructure.

Without suitable application-layer protection, some network traffic could potentially be observed or manipulated by an attacker with the necessary access.

HTTPS protects the content of the browser’s TLS connection against these kinds of network attacks.

However, HTTPS does not eliminate every danger associated with public networks.

It does not prevent someone from creating a deceptive website, tricking users into downloading malware, or exploiting unrelated security weaknesses.

Wi-Fi also has its own connection and encryption mechanisms, which operate separately from HTTPS.

These are explained in How Does Wi-Fi Work?.

HTTPS vs. VPN: What’s the Difference?

HTTPS protects communication between the browser or another client and its TLS endpoint.

A VPN establishes an encrypted tunnel between a device or network and a VPN endpoint, depending on the VPN technology.

These technologies can protect different portions of a communication path.

For example, a VPN provider may carry traffic from your device to the VPN server, while HTTPS independently protects the web connection to its destination.

A VPN does not eliminate the need for HTTPS.

Likewise, HTTPS does not automatically hide all of your network activity from your ISP.

What Does HTTPS Not Protect?

HTTPS is important, but its security has boundaries.

HTTPS Does Not Guarantee a Legitimate Website

A fraudulent website can obtain a valid TLS certificate for a domain it controls.

For example, an attacker may register a domain that resembles a legitimate business.

The attacker can then configure HTTPS for that deceptive website.

The browser may establish an encrypted and correctly authenticated connection to the fraudulent domain.

The connection is encrypted, but the website can still be malicious.

Users must therefore distinguish between a protected connection and a trustworthy destination.

HTTPS Does Not Prevent Data Collection by the Website

The website receiving your information can generally access the information you intentionally submit to it.

If you enter your address into a form, HTTPS protects the transmission but does not prevent the website from receiving and storing the address.

The website’s privacy practices, database security, and access controls remain important.

HTTPS Does Not Protect Data After Decryption

TLS protects data while it travels between the endpoints of the encrypted connection.

At the receiving endpoint, protected content must be decrypted so the application can process it.

A server may then store, forward, or process the information through other systems.

Those operations require their own security controls.

HTTPS Does Not Automatically Encrypt Every Network Segment

Some websites use a reverse proxy or content delivery network (CDN).

In that arrangement, the CDN may terminate the visitor’s TLS connection at an edge server.

It can then establish a separate connection to the origin server.

The edge-to-origin connection must also use suitable security if that segment requires encryption and authentication.

An HTTPS connection to the CDN does not, by itself, establish that every downstream connection uses TLS.

This is why HTTPS should be understood as protection between cryptographic endpoints, not an unconditional promise about every system handling the data afterward.

Why Do Browsers Display HTTPS Certificate Warnings?

Browsers validate certificates as part of establishing trusted HTTPS connections.

If a certificate fails the relevant checks, the browser may interrupt the connection and display a warning.

Common reasons include:

Problem	What It Means
Expired certificate	The certificate is outside its validity period
Hostname mismatch	The certificate does not match the requested hostname
Untrusted issuer	The certificate does not establish an acceptable chain of trust
Invalid certificate chain	Required certificate validation cannot be completed
Device clock problem	Incorrect local time may make an otherwise valid certificate appear invalid

A certificate warning does not always mean that someone is actively attacking the connection.

It can result from a server configuration error or an incorrect device clock.

However, users should not ignore certificate errors when entering passwords, financial information, or other sensitive data.

Bypassing a certificate warning may remove the assurance that the browser is communicating with the intended server.

The correct response is to identify the cause rather than assume the warning is harmless.

How Do Websites Enable HTTPS?

To support HTTPS, a website operator must configure the infrastructure that handles secure connections.

The exact steps depend on the hosting platform, reverse proxy, and server software.

The general process involves several responsibilities.

Obtain a TLS Certificate

The website operator obtains a certificate that covers the appropriate domain names.

This may be provided automatically through a hosting platform or certificate-management service.

Certificate issuance and renewal can also be automated using protocols such as ACME.

Configure the HTTPS Endpoint

The server, load balancer, or CDN must be configured with the relevant certificate and private key.

It must also support appropriate TLS versions and cryptographic settings.

Use HTTPS for Website Resources

The main webpage and its required resources should use secure connections.

This includes images, scripts, stylesheets, fonts, and API requests.

Otherwise, the page may encounter mixed-content problems.

Redirect HTTP Traffic to HTTPS

Many websites redirect HTTP requests to their HTTPS equivalents.

For example:

http://example.com/page

may redirect to:

https://example.com/page

The redirect helps move visitors to the secure address.

However, an ordinary HTTP redirect does not, by itself, protect the initial unencrypted request.

Additional mechanisms can help address this limitation.

What Is HSTS, and How Does It Improve HTTPS?

HSTS stands for HTTP Strict Transport Security.

It is a security mechanism that tells compatible browsers to use HTTPS for a specified host for a defined period.

A website can send an HTTP response header such as:

Strict-Transport-Security: max-age=31536000

This example instructs the browser to remember the HTTPS-only policy for 31,536,000 seconds, equivalent to 365 days.

The number is illustrative of a commonly used policy duration, not a universal requirement for every website.

While the policy remains applicable, the browser upgrades relevant HTTP navigation attempts to HTTPS before making the network request.

MDN’s HSTS documentation describes this behavior and its role in protecting future connections.

Does HSTS Protect the First Visit?

Not necessarily.

If a browser has never received an HSTS policy for a hostname and has no applicable preloaded policy, an initial HTTP connection may still be possible.

An attacker interfering with that connection could attempt to prevent the user from reaching HTTPS.

HSTS preloading can address this situation for eligible domains by allowing browsers to include HTTPS-only policies in advance.

However, preloading and applying HSTS to all subdomains require careful configuration.

A website operator must ensure that the affected hosts support HTTPS correctly before enforcing such a policy.

What Is Mixed Content on an HTTPS Website?

Mixed content occurs when a securely loaded webpage attempts to retrieve certain resources using insecure HTTP connections.

For example, imagine this HTTPS page:

https://example.com/article

It contains an image request:

http://example.com/image.jpg

Even though the main webpage uses HTTPS, that image request is initially specified using HTTP.

This creates a potential security problem.

An attacker on the network could attempt to observe or modify a resource transferred without encryption.

Scripts and stylesheets can be especially sensitive because they may influence page behavior.

Modern browsers mitigate mixed-content risks by automatically upgrading some insecure resource requests to HTTPS and blocking other types.

According to MDN’s mixed-content guide, browsers distinguish between resources that may be automatically upgraded and those that must be blocked.

This explains why some HTTPS pages display missing images, broken scripts, or browser security warnings.

The website may use HTTPS for its main document while still referencing resources through insecure URLs.

A complete HTTPS implementation must account for the resources that make up the page, not merely the address displayed in the browser.

Does HTTPS Make a Website Slower?

HTTPS introduces cryptographic processing and connection-establishment requirements.

However, modern TLS is designed to provide strong security while supporting efficient communication.

TLS 1.3 reduces unnecessary handshake complexity compared with older designs.

Connection reuse and session resumption can also reduce the overhead associated with subsequent communications.

HTTP/2 and HTTP/3 support additional transport and request-management improvements.

However, HTTPS does not automatically make a website faster or slower by a fixed amount.

Performance depends on factors such as:

• Network latency.
• Server and client capabilities.
• TLS configuration.
• Whether an existing secure connection can be reused.
• HTTP version.
• Resource sizes and application behavior.

For HTTP/3, QUIC integrates transport and TLS security mechanisms to establish protected communication efficiently.

However, performance still depends on real network conditions and implementation details.

The practical distinction is that encryption has computational and protocol costs, but those costs must be considered alongside the security benefits and the efficiencies of modern web protocols.

Does HTTPS Protect Every Page on a Website?

HTTPS protects resources requested through properly established HTTPS connections.

A website may support HTTPS on some hostnames or resources while others remain incorrectly configured.

For example, the following addresses are different origins:

https://example.com

https://shop.example.com

Even though both use the same registered domain, the HTTPS endpoint must be configured to authenticate the hostname being visited.

A certificate may cover several hostnames, but it must actually include the relevant name under applicable certificate matching rules.

The site’s internal links, redirects, embedded resources, and subdomains should also be configured consistently.

This is one reason securing a website requires more than obtaining a certificate for its homepage.

Why Is HTTPS Important?

HTTPS provides a foundation for trustworthy communication across untrusted networks.

It helps protect sensitive information from interception and modification during transmission.

It also gives browsers a mechanism to authenticate the endpoints of secure web connections.

These capabilities support everyday activities such as logging into accounts, submitting forms, exchanging private messages, and accessing web applications.

HTTPS also enables the secure contexts required for many modern browser capabilities.

However, it works alongside other systems, including DNS, application security, access controls, browser protections, and safe website operation.

A website can use HTTPS correctly while still having vulnerabilities in its application or backend infrastructure.

HTTPS is therefore a fundamental security requirement, not a complete security solution.

HTTPS Protects the Connection, Not Everything Behind It

HTTPS works by combining HTTP communication with TLS encryption and authentication.

The browser locates the destination, establishes a secure connection, validates the server’s identity, and derives shared keys that protect HTTP requests and responses.

These mechanisms help prevent unauthorized network observers from reading or silently changing transmitted content.

But the protection has clear boundaries. HTTPS does not guarantee that a website is legitimate, prevent the destination from collecting data, or conceal all connection metadata.

Its essential contribution is that information can travel through an untrusted network while remaining confidential, authenticated, and protected against undetected modification between the TLS endpoints.