How to find your LinkedIn li_at session cookie

Here is the short version. Open LinkedIn in Chrome, press F12, click Application, open Storage then Cookies in the left sidebar, select https://www.linkedin.com, find the row named li_at, and copy what is in the Value column. That string is your LinkedIn session.

Now the part worth reading. That string is not your password, and treating it as if it were goes wrong in both directions. Some people paste it into anything that asks. Others refuse to touch it and hand over their actual LinkedIn password instead, which is the worse of the two by a distance. So: what it is, how to get it in each browser, and how to take it back.

What li_at actually is

When you sign in, LinkedIn gives your browser a cookie named li_at. Every request your browser makes afterwards carries it, and LinkedIn checks that cookie instead of asking for your password again. Anyone holding the string is signed in as you, from any machine, until the session ends.

Two flags on that row matter, and you can see both in the screenshot. li_at is marked HttpOnly, which means scripts running on the page cannot read it. That is why typing document.cookie into the Console shows you a pile of other LinkedIn cookies and never the one you came for, and it is why LinkedIn tools ship browser extensions: an extension can be granted cookie access that page JavaScript is deliberately denied. It is also marked Secure, so it only ever travels over HTTPS.

The useful difference from a password is about blast radius. A password unlocks every session forever, including ones that do not exist yet, and on most accounts it is also the reset path for the email address. A session cookie unlocks one session and dies with it. That gap is why the cookie is the safer of the two things to hand over, and why most LinkedIn tools ask for it first.

Chrome, Edge, Brave and Arc

They are all Chromium, so the panel is identical.

1. Sign in to LinkedIn in the browser you actually use for LinkedIn. Not a fresh incognito window: you want the session you keep.
2. Press F12, or right-click the page and choose Inspect.
3. Click the Application tab. If you do not see it, click the >> chevron in the tab bar.
4. In the left sidebar open Storage, then Cookies, then click https://www.linkedin.com.
5. The table is sorted by name. Scroll to li_at.
6. Click the row and copy the Value. It is long and usually starts with AQ. Take all of it, with no spaces or quotes on either end.

The columns next to it are worth a glance while you are there. Expires / Max-Age tells you when this session dies. HttpOnly and Secure will both be ticked.

Firefox

Firefox calls the panel Storage rather than Application.

1. Open the Web Developer Tools from the Browser Tools submenu, then select the Storage panel.
2. Expand Cookies in the left tree and click the LinkedIn origin.
3. Find li_at in the table and copy its value from the detail pane on the right.

Mozilla's documentation is worth knowing about here: the Storage Inspector is read-only, and there is a search box at the top of the table that filters it. Type li_at and skip the scrolling.

Safari

Safari hides its developer tools until you ask for them, and the setting was renamed in recent versions. Apple's current instruction is Safari > Settings > Advanced, then tick Show features for web developers. Older macOS releases called it Preferences and Show Develop menu in menu bar, which is what most guides still tell you; if you are following one of those and cannot find the checkbox, that is why.

Then open Develop > Show Web Inspector, click the Storage tab, choose Cookies, and find li_at.

How long does it last?

There are two answers here, and the second is the one that matters.

LinkedIn does not publish a session lifetime, so nobody can honestly quote you one. Anyone giving a fixed number is guessing, or repeating someone else's guess. The Expires / Max-Age column in the screenshot above is dated, and it is the only answer that applies to your account.

The longer answer is that it depends on what you paste it into, which is not obvious and catches people out. A tool that saves the string in its database and replays it on every request is holding a photograph of your session, and photographs go stale. A tool that consumes the string into a real browser session is holding something live: LinkedIn replaces the cookie with its own on the first page load and keeps rotating it from there, so the session stays current as long as it keeps being used.

Ours is the second kind. The string you paste is an entry credential. It opens an encrypted browser profile on our side, LinkedIn takes over the cookie from there, and the string you gave us is never written to our database. The practical difference is that the same pasted cookie tends to keep working far longer, because what is being kept alive is a session and not a copy of a string. If you have had cookies die on you in a week somewhere else, that is the reason.

What definitely ends it, whatever the tool: signing out. Signing out of LinkedIn invalidates the session that cookie represents, and the copy you saved somewhere else stops working at the same moment. This trips people up constantly. They connect a tool, then sign out of LinkedIn on their laptop that evening out of tidiness, and wonder in the morning why the tool says the session expired. It is not the tool.

Two more things from LinkedIn's own help pages, in case they explain something odd you are seeing. Keep me logged in works on up to five devices, and it is unavailable while two-factor authentication is on. And if you sign out, LinkedIn may sign you straight back in on a device you have used before, which creates a new session rather than resurrecting the old one.

How to take it back

This is the part most guides leave out, and it is the reason handing over a cookie is a reasonable thing to do at all. You can end it whenever you like, without changing your password and without locking yourself out of anything.

On desktop: open Settings & Privacy, go to Sign in & security, and click the arrow next to Where you're signed in. LinkedIn lists every active session with the browser, the IP address and the city it was signed in from.

From there you have two options. END, next to a single session, kills that one. Sign out of all these sessions, at the top of the list, kills everything: it asks for your password, then you click End session.

Read that list before you do anything else. If you have ever connected a LinkedIn tool, its session is in there, and so is every browser you have forgotten about.

Before you paste it into anything

A session cookie is a key to your LinkedIn account. Handing one over is a normal, reversible thing to do, and it is still worth thirty seconds of thought, especially if the account is a client's rather than yours.

• Does the tool tell you what it does with the cookie? Storing the raw string in a database is not the same as consuming it into an encrypted browser session and throwing the string away. Vendors who do the second one tend to say so, because it took work.
• Does it say what it will do with the account? Reading your own messages and blasting five hundred connection requests are both "LinkedIn automation" and they carry entirely different risk.
• Is there a delete path, with a number attached to it? "We take privacy seriously" is not a retention policy. "Deleted after 7 days if you do not come back" is.
• Would you be comfortable if the account belonged to your best client? For a lead-gen agency it usually does.

If you want to see how we answer those four for our own product, that is what the safety page is: per-account daily budgets, business-hours pacing, one proxy per account, and a review queue in front of every send.

Two ways to avoid the DevTools trip

The cookie route is the manual one. It exists because it always works, on any browser, with no software installed, and because some people would rather hand over a revocable session than anything else. Fair.

There are two easier paths, and most tools offer at least one.

A browser extension. It reads the cookie with the permissions a page script is deliberately denied, so the six steps above collapse into one click. Ours is on the Chrome Web Store: install it, open LinkedIn, click the icon. You never open DevTools at all. If you connect accounts regularly, which agencies do, use this one.

Your LinkedIn email and password. A bigger thing to hand over, and it buys you something neither cookie route can: you stop being asked to reconnect. A cookie is a session, and sessions end eventually. When one does, a cookie-based tool has to stop and ask you for a fresh string, and on a client's account that means an email, a wait, and a hole in the sending while nobody notices. Hand over credentials and the tool signs back in by itself. LinkedIn may ask for a two-factor code, which gets relayed to you to type in, and after that it is quiet.

If you want to watch the cookie route actually do something before you commit to anything, our Ghostwriter is free and takes exactly this cookie. It reads up to 500 messages you have sent, works out how you write, and lets you interview the result. It is read-only, nothing is ever sent from the account, and unclaimed data is deleted after 7 days.

Takeaway

In Chrome it is F12, Application, Storage, Cookies, linkedin.com, copy the value of li_at, and the Console will never show it to you because the cookie is HttpOnly. If you would rather skip all of that, an extension does the same job in one click. And whatever you connect it to, you can end the session from Settings & Privacy under Where you're signed in, which is worth checking before you hand it over rather than after.