Answers · The network and the web
If a website has HTTPS, can someone on the same Wi-Fi read my password?
In shortNo. HTTPS encrypts the form contents and cookies, so someone on the same Wi-Fi cannot read the password itself; they can still see the site, timing and packet sizes.
No, not the password itself. When HTTPS is working and the certificate is valid, the characters you type into a password field are encrypted before they leave your device, so somebody on the same Wi-Fi sees a connection to the site, not the password inside it. The rest of what they see is metadata: which site, when, how much data, and in which direction.
What the padlock covers
HTTPS is not a cloak over the whole connection. A packet is an envelope with a letter inside. The envelope has to carry the destination and source addresses, the size and the timing, because every machine on the path uses those to deliver it. Encryption applies to the letter: the request body, the response body, the cookies and the headers inside the encrypted channel. A watcher cannot read those bytes, and cannot alter them without the change being detected and the connection being aborted. That second part matters as much as the first. An attacker who can silently rewrite a script in a page has a complete compromise, and the integrity check is what stops it.
Take a sign-in as a concrete shape. The reader submits a form. The watcher sees two small packets leave the device and one reply of about 14 kilobytes come back. Later the reader opens a statements page: a request of about 6 kilobytes goes out, then 31 packets arrive totalling about 240 kilobytes. None of those bytes are decrypted. The watcher does not need to decrypt them. The comparison is arithmetic: the sign-in reply is 14/6, about 2.3 times the size of the later request, and the later page averages 240/31, about 7.7 kilobytes per packet. That pair of numbers, plus the order, is a fingerprint. A failed sign-in returns a differently sized page, so the watcher also learns whether the attempt worked. The page opened can be identified by matching the sizes against a recording the watcher made by visiting the same site.
The natural guess
The natural guess is that the padlock makes the connection invisible. It does not. Encryption hides contents and nothing else. The addresses, the timing, the sizes and the direction of every packet stay in the clear by necessity. The site name has historically travelled in clear text twice: once in the lookup that turns a name into an address, and once at the start of the handshake, because a single address often hosts thousands of sites and the server cannot choose the right certificate until it knows which site is wanted. Encrypted lookups and encrypted client hello exist, but neither is universal. A watcher needs only one of those two clear-text moments to learn the site.
What a watcher can still do
With sizes and timings alone, an attacker can often tell which page of a site was opened. The published accuracy is high, with most misses confused between similar pages on the same site. The defence is padding, which costs bandwidth roughly in proportion to how much it helps, so ordinary sites do not deploy enough of it. The sharper case is a page that sends a request per keystroke to offer suggestions. Each character typed produces a small packet, and the reply size depends on how many suggestions matched. Encryption does not help, because the leak is in the sizes rather than the contents. This can recover search terms and, in some designs, which item was selected from a list. It is an inference from traffic shape, not a reading of the password field.
Where this stops being true is at the endpoints. HTTPS protects the message between your device and the server. It does not protect against a site that stores your password badly, a device already infected with malware, or an attacker who controls your device. It also does not protect you if you click through a certificate warning: at that point the browser has told you the certificate does not match the name, and a fake site on the same Wi-Fi can then read everything you type. The certificate proves that the server you reached holds a key for that name. It does not prove that the site is honest, well run, or the site you intended. The same distinction applies to the form itself. A page can load over HTTPS and still post the password to an http address, in which case the padlock on the first page protects nothing about the submission.
Worth keeping
- HTTPS hides the contents of a message and detects tampering, but it leaves the addresses, timing, sizes and direction of packets visible to anyone on the path.
- A watcher on the same Wi-Fi can learn which site you used, when you signed in and which page you opened from packet sizes and timings, even when every byte of content is encrypted.
- The password itself is not readable on the network when HTTPS is working and the certificate is valid; the remaining risks are the endpoints, certificate warnings and side channels in how the site sends data.
Where this goes next
This question is one step of How a Message Stays Private, a course that works through its subject from the beginning. The page that teaches this part of it is What a Watcher Can See, and it reads the whole way through whether or not you have an account.
What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.
Read that pageThe whole courseOther questions people ask about this
- Why does the TLS handshake take so many round trips before any data is sent?It is not one key exchange. The handshake agrees a secret, proves the server's identity and checks for tampering, and modern TLS fits those into one round trip; a fresh connection still needs three before the page starts.
- How can two computers agree on a secret key when anyone can listen?Each computer sends a scrambled number made from a private number; the shared key is made by scrambling the other computer's number with one's own private number, and a listener cannot unscramble it.
- How does a man-in-the-middle attack still work if the key exchange is secure?A key exchange proves only that you share a secret with whoever answered. An attacker on the path answers you themselves and opens a second exchange to the real server, so both halves look secure.
- Does HTTPS hide the domain name of the site I'm visiting from my ISP?Usually not: the site's name is sent in readable form twice, once when your computer looks up its address and once when the secure connection opens.
- Where should a session ID be stored so JavaScript can't read it?Store it in an HttpOnly cookie set by the server; that is the only browser storage JavaScript running on the page cannot read.
- What does it mean for an API method to be safe?A safe method is one that changes nothing on the server when it is called, so a caller may repeat it freely and a cache or a crawler may use it without anything being altered.