Debugging auth sessions by editing cookies in Chrome

A user reports they are stuck in a login loop, but only sometimes, and only since Tuesday. You cannot reproduce it on your account. The difference, nine times out of ten, is session state: a stale cookie, a locale cookie pointing at the wrong region, a feature flag cookie your account does not have. To debug it, you need to see the cookies, change one thing at a time, and reload.

Here is how to do that with the tools already in Chrome, and then the extension I built to make the same job faster.

The built-in DevTools path (no install needed)

Chrome DevTools can do most of this, and if you only edit cookies once a month, it is enough:

1. Open DevTools (F12) and go to the Application tab.
2. In the left panel, expand Cookies and pick the site's domain. You get a table of every cookie: name, value, domain, path, expiry, and the HttpOnly, Secure, and SameSite flags.
3. Double-click a value to edit it in place, right-click to delete a row, and use the clear-all button at the top to wipe the site's cookies for a clean session test.

Honest limits of the built-in path: there is no convenient import or export, so moving a known-good session state from a test account to your browser means copying values one at a time. Editing flags and expiry dates is clumsier than editing values. And the table is buried three clicks deep every single time, which adds up when switching test accounts is something you do ten times a day.

The same job with a dedicated editor

Disclosure: CookieSmith is my own extension, built because EditThisCookie, the tool a lot of us used for years, was removed when Chrome dropped Manifest V2 support, and some of the copycats that rushed in were not trustworthy. CookieSmith is a Manifest V3 rebuild of that workflow: open source, no telemetry, and no network requests, which you can check yourself in DevTools.

The workflow for the login loop case:

1. Open the site, click the CookieSmith icon, and you get the current tab's cookies in one popup, with flag indicators (Secure, HttpOnly, SameSite, session versus persistent) visible without expanding anything.
2. Search by name to find the session or locale cookie, click it, and edit the value, flags, or expiry in place. Reload and see whether the bug reproduces.
3. To match a customer's or a test account's state exactly, export their cookies as JSON from that browser profile and import the file in yours, instead of hand-copying values. The JSON format is compatible with the old EditThisCookie export format and with common test automation workflows.
4. When you need a truly clean start, delete one cookie, or clear all cookies for the site, from the same popup.

CookieSmith is free, and it is here: https://chromewebstore.google.com/detail/cookiesmith-cookie-editor/pegoacenbkcalnblooiehmeicihaggpo

A caution that applies to both methods: cookies are session credentials in practice. Anyone with your session cookie can often act as you on that site, so treat exported cookie files the way you treat passwords. Do not paste them into tickets, chat, or shared docs, and delete exports when the debugging session is over. CookieSmith keeps everything local and sends nothing anywhere, but what you do with an export file is on you.

If you switch test accounts, locales, or feature flags for a living, a one-click editor saves real minutes every day. If you do not, DevTools already has you covered, and now you know where it hides.