Is HTTPS Encrypted Everywhere?
The Journey of Your Data
The Short Answer: No
The content is not encrypted everywhere. It is encrypted only while it is traveling over the network. Once it reaches either endpoint (your browser or the server), it exists in plaintext in memory so it can be processed. HTTPS protects data in transit, not data at the endpoints.
# In this article
1. The Journey of an HTTPS Request
2. Location & Encryption Status
Let's go through every stage and see where your data is safe and where it can be read.
| Location | Encrypted? | Can someone read the content? |
|---|---|---|
| Browser JavaScript memory | ❌ No | Yes (browser/process) |
| Browser → Network Card | ❌ Briefly | Operating system can |
| On Wi-Fi | ✅ Yes | No |
| ISP | ✅ Yes | No |
| Internet Routers | ✅ Yes | No |
| CDN/Load Balancer (TLS terminates) | ❌ After decryption | Yes |
| Web Server | ❌ No | Yes |
| Database | Depends | Depends on DB encryption |
3. Example: Submitting a Login Form
Suppose you login with Username: mayank and Password: MyPassword123.
1. Inside the browser
This is plain text inside browser memory.
POST /login username=mayank password=MyPassword123
2. On the internet
Then TLS encrypts it. It becomes binary bytes. ISP sees something like:
0x7A 0x12 0xFF 0x91 0xD8 0xEE 4AF7C2D91AB7F9EAD2...
They cannot recover the password without the session keys.
3. Server receives it
The server decrypts it. Now again it becomes plain text for the web application to read.
POST /login username=mayank password=MyPassword123
4. Where is it visible in raw form?
1. Browser Memory (Dev Tools)
Open your Network tab and click a request. You can literally see your password (before the browser masks it in the UI). The browser obviously knows the content because it created it.
2. Browser Extensions
A browser extension with permission can read form fields, headers, cookies, and POST bodies before encryption. For example, password managers like Bitwarden or 1Password.
3. Malware / Keyloggers
A keylogger doesn't care about HTTPS. It simply records M y P a s s w o r d while you type. HTTPS cannot protect against this because the data is captured before encryption.
4. Corporate Proxies
Many companies install their own trusted certificate to perform TLS inspection. The proxy acts as a trusted intermediary, decrypting, scanning, and re-encrypting the traffic.
5. Load Balancers
Many websites terminate HTTPS at a load balancer (e.g., AWS ALBs). The load balancer decrypts the traffic and may send it via HTTP to the application server depending on internal infrastructure.
6. Application Logs
Poorly written applications sometimes log raw requests to log files. While modern frameworks try to mask sensitive fields, plaintext data can sometimes slip into logs.
5. What does Wireshark see?
Without HTTPS:
POST /login username=mayank password=MyPassword123
With HTTPS:
TLS Application Data 4F B2 C1 99 8A ...
Wireshark cannot decode it without the session keys.
6. Can the ISP see anything?
Even with HTTPS, the ISP can usually observe metadata.
What they CAN see:
- Your IP address
- The destination IP address
- The amount of data transferred
- Timing of connections
- Often the domain name (via DNS or TLS SNI, unless Encrypted ClientHello is used)
What they CANNOT see:
- URLs after the domain (e.g., /account/orders)
- Form data
- Passwords
- Cookies
- API responses
- Chat messages
7. Real-world example: Gmail
When you send an email like "Hello Rahul, Meet me tomorrow at 5 PM.", the message is:
- Plaintext inside your browser.
- Encrypted while traveling over the Internet via HTTPS.
- Decrypted at Google's servers so Gmail can store, index, and deliver it.
- Encrypted again while traveling to the recipient's browser.
- Plaintext again in the recipient's browser.
A Simple Rule to Remember
- • In transit (between browser and server): Encrypted.
- • At the browser: Plaintext in memory.
- • At the server: Plaintext in memory after decryption.
- • At rest (stored on disk/DB): Depends on the application's storage encryption; HTTPS itself does not provide this.