Facebook cookies and session persistence in 2026: engineering guide

One of the most important technical questions in Facebook automation is: how do you maintain a stable login state for weeks and months without letting the bot re-login every day? Every re-login attempt is an opportunity for an SMS code, captcha, or checkpoint — any of which can take down your bot until you intervene manually.

In this article I'll break down Facebook's cookie system as it looks in 2026, explain what each cookie does, what its lifetime is, what causes Facebook to "reinvent" the user as logged out, and how to build a session persistence scheme that lasts months. BuzzPost solves this automatically for every customer, but if you're building your own — this is for you.

Facebook's cookie agreement (2026)

Facebook maintains login state through 6 main cookies. Here's the list:

c_user — the visible identifier

The only cookie that's not HttpOnly, meaning JavaScript on the page can read it. This is the user's UID, a number like 100012345678901. By itself it doesn't authenticate you — it only tells Facebook "I am this user" — but combined with xs it makes up the full identity.

xs — the session token

The most important cookie. It contains a complex hash encoding the user ID, login time, and server secret. Without a valid xs, Facebook doesn't know you — you'll get a login screen. In 2026 the xs is JWT-like; you can see 3 parts separated by %3A.

Its lifetime is ~90 days, but it auto-refreshes if you browse regularly. That's our 13-day window: BuzzPost refreshes cookies about every 13 days, so xs never approaches expiry.

datr — pre-login fingerprint

The most "sneaky" cookie. It's installed the moment the browser lands on facebook.com, even before the user logs in. It's used to track the same browser across sessions. If you change the profile every time (deleting user-data), datr changes — and that's a strong negative signal to Facebook. One of the reasons you must never delete your Chrome profile.

fr — browser fingerprint

The cookie containing the browser's full fingerprint. An encoded value including IP, UA, screen, plugins. When Facebook runs a security check, it compares the current fr with the original fr from login. If they differ — checkpoint.

sb — secure browser identifier

The longest-lived cookie. 2-year lifetime, and not renewable without full re-login. Essential for long-term account authenticity.

What causes Facebook to do an immediate logout?

Facebook doesn't rely on cookie expiry alone. It periodically runs security checks that can "drop" the session even if the cookies are valid. Here's the list:

1. IP change

Reason #1 for logout. If the account originally logged in from an Israeli IP and suddenly arrives from a Russian IP, Facebook panics. Solution: VDS with static IP, configured for one specific account. At BuzzPost every VDS has a separate fixed IP — an account always logs in from the same address.

Exception: IP change due to provider switch (rotating residential proxy) or carrier swap on a phone is considered "natural." Facebook won't throw a checkpoint over that. But a jump from ISP A's static IP to ISP B's static IP within 10 minutes — suspicious.

2. User-Agent change

If a user switches from Chrome to Firefox, Facebook knows and may demand re-login. In a bot, the UA must be identical always. At BuzzPost the UA is set once in the profile and fixed — Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 or similar. If Chrome updates to a new version, we maintain the UA after update.

3. Screen resolution change

Also a fingerprint. Our VDS runs at 1366×768 by default. Changing resolution (e.g., a larger RDP) → checkpoint. With us: resolution lockdown in the Windows registry.

4. "Suspicious" activity

If the bot performs 50 actions per minute (too fast), or 0 actions for 4 hours after login (also weird), Facebook will throw a checkpoint. Our bot randomizes 8-22 seconds to match a human pattern.

5. Login from another device

The most critical: if the user (or you) logs into the same account from a phone or another computer while the bot is active, Facebook sees two sessions and kills one. Clear instruction to customers: don't log into your Facebook manually from a personal phone while the bot is running. If you must, connect to the VDS via RDP, not from a new device.

The method: cookie persistence in user-data dir

The standard way to preserve cookies between Chrome sessions is saving the user-data directory. This folder (sometimes more) contains all cookies, history, cache, localStorage, sessionStorage, and more.

In Chrome, the user-data dir is specified by a launch flag:

chrome.exe --user-data-dir=C:\Users\Administrator\AppData\bot_chrome_profile

At BuzzPost, we always launch both bots (FB + Marketplace) on the same --user-data-dir. This saves memory and ensures they share an identical cookie store. If they ran on separate profiles, Facebook would see two logins of the same account from the same IP simultaneously — leading to a ban.

The cookies file itself is at {user-data-dir}/Default/Cookies — a SQLite file. You can read it manually with:

sqlite3 Cookies "SELECT name, value, expires_utc FROM cookies WHERE host_key LIKE '%facebook.com'"

The 13-day window

At BuzzPost there's unique logic: if a cookie hasn't been refreshed in the last 13 days, a warning is raised. Why 13? Because xs is considered "fresh" for about 14 days based on the models we identified, and we want a 1-day safety margin. If the user hasn't browsed for 13 days, we perform light automatic browsing (load home, click notifications, open marketplace) to refresh cookies before they expire.

This mechanism ensures almost no account needs re-login. When one is needed (after a checkpoint or 2+ weeks offline), the system shows an alert to the owner and asks for confirmation.

Recovery strategy: when re-login must happen

When it does happen, it's important to do it as "naturally" as possible:

1. Open Chrome with the same user-data dir — don't clean anything. datr, sb, fr are still there.
2. Navigate to facebook.com normally, not to login.php. So you don't look like a ready-made tool.
3. Wait 5-15 seconds before the bot touches buttons. Fingerprint timing.
4. Type email and password at 50-150ms between keystrokes, not paste. Randomization.
5. After login, browse 30-60 seconds without posting. Let fr and xs settle.
6. If 2FA is requested — pass the request to the user. The bot can't handle TOTP.

These steps reduce the chance Facebook will throw an immediate checkpoint on a new login from ~30% to ~5%.

Secure storage of credentials

If your bot saves email and password for automatic re-login, where do you store them? Not in a plain text file. At BuzzPost:

• Passwords are encrypted with Fernet (Python cryptography) in a central database.
• The decryption key resides only on the specific VDS server, not on the panel server.
• The panel server doesn't know passwords, only hashes.
• VDS access is only via RDP with 2FA.

Summary

Session persistence is critical infrastructure for any Facebook bot meant to last for months. It's not just "saving cookies" — it's ensuring a stable fingerprint, stable IP, stable UA, and calibrated refresh. BuzzPost handles all of this automatically — every customer gets a dedicated VDS, separate Chrome profile, and cookie freshness monitoring on a 13-day window. You don't need to know what xs or datr is; you just enjoy an account that stays logged in.

If you want to start posting real estate in Facebook groups with a stable session — buy the first plan at 249₪/month. For more info see anti-detection or features.

Appendix: a real 2025 problem

In summer 2025 Facebook changed the encoding of xs from regular base64 to base64url + URL-encoded. Many bots that parsed the cookie manually (for debugging) got parsing errors. With us it didn't affect anything because we don't parse it — we only send it back as-is in requests. Lesson: never try to decode the xs value yourself. It's server-signed, not meant for clients to read.

Another 2025 phenomenon: sometimes fr changes to "empty value" mid-session, and Facebook demands a page reload. If your bot isn't prepared, it fails. Solution: every time a POST is performed and the response lacks fr, reload the page before continuing.

Second appendix: 2FA — how to handle

If your customer enabled 2FA on the account (TOTP, SMS, or security key), the bot cannot pass manual login without intervention. At BuzzPost the solution:

• SMS 2FA: when the bot detects a code demand, it sends a Telegram alert to the owner. The owner receives the SMS, enters the code into the panel, and the panel passes it to the VDS, which types it into Facebook. Time from detection to successful login: 30-60 seconds on average.
• TOTP (Google Authenticator): the customer provides the TOTP secret once (at setup), and the bot computes the current code. Most customers don't do this because it requires a level of trust, but it's the most automated option.
• Security key (FIDO2): not automatable. The customer needs to disable the security key on the account before using the bot.

Failure scenario: what happens when everything blows up

Suppose your Facebook account gets banned while the bot is active. Here's the sequence of events:

1. Bot performs a post. POST request goes out to Facebook.
2. Facebook returns 302 redirect to /login.php. The session is effectively canceled.
3. Bot detects the redirect (URL contains /login) and doesn't check text (stable across translations).
4. Evidence preservation: screenshot + DOM dump at _rl_evidence/checkpoint_YYYYMMDD.png.
5. Telegram alert to owner: "VDS #X — account Y banned, intervention required."
6. POST to panel: {"server_id": X, "type": "checkpoint", "evidence": "..."}
7. UI updates: server X shown in red on the main panel.
8. Bot stops. No further action until the owner manually clears the flag.

The point: the bot won't try a new login on its own. Ever. Because every unverified login attempt adds black marks. Intervention must come from the owner: manually log in, pass the checkpoint, and then return the bot to operation.