Cookies hold session tokens, feature flags, consent state and A/B assignments. When you are debugging a login flow or reproducing a customer's bug, being able to change one and reload is the difference between a five-second check and a twenty-minute detour. Chrome gives you three practical ways to do it.
Method 1: Chrome DevTools
Nothing to install, best for a quick look at a single page.
- Press F12 (or Ctrl + Shift + I).
- Open the Application panel.
- In the sidebar choose Storage → Cookies and pick the origin.
- Double-click a cell to edit the value, domain, path, expiry or flags, then reload.
DevTools lists HttpOnly cookies too, because it reads them through the browser
rather than through page JavaScript. What it does not do is bulk work: there is no import, no
export and no conversion between formats — you copy rows by hand.
Method 2: A cookie editor extension
An extension keeps the whole job in one popup and survives reloads and navigation. With CookieMan the loop is:
- Open the site and click the toolbar icon — every cookie for that domain is listed.
- Filter by name, value or domain with search.
- Click a cookie to edit any attribute, or + Add to create one.
- Save. The list and the badge count update as the browser applies the change.
The same popup imports a whole set from JSON or cookies.txt and exports in six
formats, which is what makes it useful for moving a session into curl or another profile. The
install guide covers setup click by click.
Method 3: The console, with real limits
From DevTools you can write a cookie for the current document:
document.cookie =
'theme=dark; path=/; max-age=2592000; samesite=lax';Useful, but it cannot do several things people expect:
- It cannot read or write
HttpOnlycookies — that is the entire point of the flag. - It cannot set a cookie for another site, only the current document's domain and its parents.
-
Securecookies can only be set from a trustworthy origin — HTTPS, orlocalhost. - There is no delete: you overwrite the cookie with an expiry in the past.
Why your edit did not stick
Most "the cookie disappeared" reports come down to a rule the browser applied silently. The ones worth memorising:
| Rule | What happens if you break it |
|---|---|
SameSite=None requires Secure | The cookie is rejected outright. |
__Host- requires Secure, Path=/ and no
Domain | Rejected if any of the three is wrong. |
__Secure- requires Secure | Rejected on a plain HTTP origin. |
Partitioned (CHIPS) requires Secure | Rejected, or stored in a different partition than you expected. |
| Chrome caps cookie lifetime at 400 days | A longer expiry is quietly trimmed. |
| The domain must match the origin you are on | Setting .example.com from another site fails. |
| Roughly 4 KB per cookie | Oversized values are dropped, often with no console message. |
A related trap: a host-only cookie (no Domain attribute) is not sent to
subdomains, while .example.com is sent to all of them. Copy a cookie between
environments without matching that flag and you get a session that looks present but never
authenticates.
What people actually use this for
- Testing auth — expire a session cookie by hand instead of waiting an hour.
- Flipping an experiment — change the variant cookie and reload.
- Debugging third-party cookies — check whether a cookie is partitioned or blocked inside an iframe.
- Feeding automation — export the logged-in state for curl, Playwright or CI.
For that last one the interchange format matters: see the cookies.txt explainer, curl -b cookies.txt, __Host- rejected by Chrome, or paste what you have into the online converter.
Treat exported cookies like passwords
A session cookie is a credential. Anyone holding the file can usually resume the session, so keep exports out of shared documents and support tickets, and delete them when you are done. CookieMan works entirely on your machine — no upload, no analytics — precisely because that data has no business leaving it.