What is a cookie? How does the website remember when you're logged in? I caught a bag—this receipt can sit for at most a year

Last month,

went to his hometown to help him adjust the router, and casually logged into his computer to download the firmware from a cloud drive. This week, he called me over again. When I opened the browser, the cloud drive was still logged in, and the file list was right there. I didn't let him save my password, nor did he click to log out. How could it recognize me? When I came back, I broke it down and saw the answer was just a short string of text, technically called a cookie. Today's article explains it clearly, and also addresses the old question of "Will clearing cache remove passwords?"

clarify first: a cookie is a storage token the website gives you

first starts with the inherent flaws of HTTP as a "language." I previously the difference between http and https in a of cabao, and mentioned that http has no memory. This time you request a webpage, the server forgets who you are after the server finishes the service, and the next moment you refresh, it sees a brand new face in its eyes. This is called statelessness.

places like cloud drive, email, and blog backend need to "remember you." The engineer's solution is especially rustic: When you first arrive, the server casually slips you a receipt when it responds, and it says "Number 27315." Your browser stores the tickets in a small notebook. Next time you visit this site, the browser will pull up the ticket and automatically insert it into the request and hand it over. Server pair: Oh, 27315, old acquaintance, come in.

just this round trip. A cookie is a receipt issued by the website and stored by the browser on its behalf. You feel like "the website remembers me," but it's actually the browser handing you the ticket. Change computers or browsers, the notebook is empty, no tickets to hand in, and the website will pretend it doesn't recognize you—that's why if you log in on your computer at home, you have to log in again on your phone, and each side has its own notebook.

I grabbed a bag, this receipt looks like this

just talking about metaphors isn't enough, I grabbed the real one with curl. Visiting Baidu's homepage, the server response shows a line:

Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/

disassembled section by section. BDORZ is the name of the ticket, 27315 is the ticket number, and these two are connected by equal signs, forming the main text on the bill. domain=.baidu.com said that this ticket only works on Baidu's domain; other websites don't recognize it, and browsers won't hand Baidu tickets to Taobao. path = / is the jurisdiction area, and the slash represents the site-wide usage. The most interesting is max-age = 86400—this is the validity period, measured in seconds, 86400 divided by 24 divided by 3600, which is exactly one day.

to verify "will be brought automatically next time," I saved the ticket received on the first visit into a file, then immediately accessed the original address the second time and grabbed the request header. Sure enough, a line Cookie: BDORZ=27315 appeared. I didn't do anything; the browser (here I did curl for it) handed over the ticket itself. The entire process is exactly the same as storing a bag in a mall: store the bag and give it a token, pick up the bag and hand it over. Once the card is in hand, the bag is yours.

There are two types of tickets: those that expire

the browser and those that can sit for a year

is also a cookie, with two levels of lifespan. I grabbed another comparison—I visited GitHub, and the ticket it sent out had a ticket called _gh_sess, followed by path=/; HttpOnly; Secure; SameSite=Lax, but no expires or max-age. Tickets without expiration date are recorded by the browser as a "session cookie." Once the window closes, the ticket is voided along with the session. Most of these tickets are installed in temporary login mode, so on some websites, if you close your browser and open them again, you have to log in again. It's not that the ticket is broken, but that the ticket is designed to be one-time only.

other tier is persistent cookies with a clear expiration date. GitHub also issued a _octo ticket. The day of the packet capture was October 2026, and its expiration page said Mon, 04 Oct 2027—a full year. These tickets are stored on the plate; even when the browser is closed and restarted, the computer reboots, they remain and are destroyed on their own. Next to the website login box, the "Remember Me" checkbox. Whether or not you check the box usually depends on whether your invoice has an expiration date: if you check 'issue a lasting invoice,' you won't issue a session ticket.

the most fun thing is that among those GitHub tickets, there's one named logged_in, and the value is no. In other words, the question of "whether you logged in or not" is just a single word on a cookie on their platform. After logging in, the server updates it to yes, and the browser stores it for a year. Next time you visit, the browser will send this yes icon, and the top right corner of the page will show your avatar. The so-called login status is essentially just that simple.

cache clearing and logout at which level? Don't mix the three layers together

this is the most frequently asked question and also the easiest to get wrong. First, place three layers of things on the table, which are located in different drawers in the browser:

so the answer is split in two: in the browser, click "Clear browsing data," and the pop-up checkbox for cookies, password, and cache are three separate checkboxes. If you only check the cache, both the password and login mode are fine; If you check cookies, the login state disappears but the password database remains, and the account password can still be automatically filled in the next time you log in—provided you saved it before. in my article about changing management passwords I mentioned the old browser stuffing, which refers to the password library drawer, which is different from cookies.

By the way, Windows also has a fourth drawer called the credential manager, which stores system-level accounts like LAN sharing and mapping disks. My cousin even reported 'System Error 1219' on his NAS at the time. The root cause is there, and it doesn't even connect to browser cookies. See NAS for details. Can't connect to that credential cache check.

Once

the layers are clarified, "logout login" becomes easier to understand. Clicking that button, the backend actually does two things: first, the server invalidates your ticket number in its own registry; second, it has the browser tear up the tickets in your hand. Only when both sides are cleared together can it be considered a clean exit.

many people simply close the webpage on shared computers. This is where the problem arises: the ticket is still lying in the browser, especially the persistent cookies, which are still registered the next time you open them. The cloud drive on my small computer is exactly like this. What's even more troublesome is that even if you only clear the cookies on the browser's side, the server's registry remains untouched—the ticket number is still in the register, but you just don't have the ticket anymore. It may sound trivial, but if you think about it the other way around, it becomes clear: if the ticket is copied elsewhere (for example, a middleman copying it, or a malicious script on your computer flipping through your notebook), the ticket holder is the legitimate you.

the iron rule of sharing a computer is to use the official "Log Out" button, not just close the webpage; Before lending your computer to someone else, make sure to log in completely. I wrote about a about router hacking, which reminded you to change your password after getting scammed, but you were still half sentence short: after changing the password, also clear your browser cookies to void all your old tickets, then you'll be able to close the door tightly.

HttpOnly and SameSite, the two lines of small text on the back of the ticket are life-saving

looking back at the three suffixes on the GitHub _gh_sess ticket, each has its own details.

HttpOnly means this ticket can only be passed back and forth at the HTTP layer; JavaScript on the webpage cannot be touched. Why is it important? Because there's a type of attack called XSS, which works by inserting a bad script into the web you browse. Once the script runs, it digs through your browser's small notebook and copies your login password and sends it to the attacker. If the ticket says HttpOnly and the script can't be accessed, this trick is mostly useless. Baidu's BDORZ doesn't have this suffix, because it's a statistical ticket, so losing it doesn't matter; Tickets registered in status are generally printed on them.

Secure is "This vote only goes through the crypto channel." Tickets with this suffix, HTTP plaintext channels, are never submitted; only HTTPS are accepted. Thinking about it, it makes sense. http is clearly running naked . If you take this route for the registration ticket, it's like holding your house key in your hand and walking at night.

SameSite=Lax It's a different matter: can other websites deliver tickets for you? The normal process is: "You operate on the Baidu page yourself, and the browser hands over Baidu's ticket to Baidu." But embedded images or links on webpages can also trigger requests to third-party websites, allowing attackers to create phishing pages to lure your browser into using your ticket on a certain site to do bad things. This is called CSRF. SameSite restricts that only requests made from this site page allow ticket inclusion; phishing sites want to borrow your ticket, but there's no way. These three phrases are usually used during website development without you having to do them yourself, but once you understand them and encounter security news, at least you know what it's saying.

conclusion: A single form clearly states who manages what

in the end, cookies are just tools—websites rely on them to recognize people, and you can enter your password fewer times. The criticisms it carries—ad tracking, privacy leaks—are mostly due to its actions; the votes themselves are not inherently sinful. In your browser settings, you can see the name and expiration date of each ticket. If you have a chance, just glance at your frequently used stations and see which tickets last a year, and which expires when you close the browser. It's quite interesting. As for the cloud drive on my small computer, I logged out and logged in before leaving, and I also turned off the browser save password—that was another account in the password drawer.