Debugging auth sessions by editing cookies in Chrome

Cliff Kosick — Mon, 19 Oct 2026 14:10:53 +0000

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:

Open DevTools (F12) and go to the Application tab.
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.
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:

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.
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.
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.
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.

How to stop losing long form entries while testing

Cliff Kosick — Mon, 19 Oct 2026 14:10:09 +0000

You know the moment. You have spent twenty minutes filling in a long test case, a bug report with exact reproduction steps, or a support reply that finally says the thing right. Then the session times out, the tab crashes, or the submit button bounces you to a login page. The form comes back empty. The work is just gone, and the only copy was in your head.

Testers and data entry folks hit this more than anyone, because long forms are the job. Here are the workarounds that actually help, in the order I would try them, and then the tool I ended up building when the workarounds were not enough.

The honest manual workarounds

Draft somewhere else first. For anything longer than a paragraph, write it in a notes app or a local text file and paste it in at the end. This works, and it is still the most reliable method there is. The cost is friction: you have to remember, every time, before you start typing, and the one time you forget is the time the session expires.

Use the browser's back button carefully. After a failed submit, going back sometimes restores form contents, because browsers do cache some field values. Sometimes is doing a lot of work in that sentence. It depends on the site, on cache headers, and on whether the page re-renders the form from scratch. Treat it as a lucky recovery, not a plan.

Check for a drafts feature. Gmail saves drafts. Some support desks and CRMs autosave. Many long web forms, especially government, insurance, and job application forms, save nothing at all. Worth a look before you assume the text is gone, useless as a general strategy.

Shorten the exposure. If a form allows it, submit in stages, save partial entries, or keep a running copy of the longest answers in a side document as you go. This reduces the size of a loss rather than preventing it.

The scenario, with a safety net

The pattern that kept burning me was forced session timeouts during testing: log in as a test user, fill the form, get pulled into a meeting, come back to an expired session and an empty form.

So I built FormKeep, and full disclosure, this is my own extension. It watches text inputs, textareas, and rich text editors as you type and saves local snapshots in the browser. When a tab crashes, closes, or a submit fails, you open the popup, find the snapshot grouped by site, and restore it into the field in one click. There is also a right-click menu item and an Alt+Shift+R shortcut for the same restore.

The test I ran on myself, and the acceptance test the extension had to pass before I published it: type a long paragraph into a form, kill the tab, reopen the page, restore. The text came back intact, with undo history working the way it should.

Two design points mattered to me more than the recovery itself. First, everything stays on your machine. Snapshots live in your browser's local storage, the extension makes no network requests at all, and you can verify that in DevTools in about a minute. Second, password fields, PIN inputs, and two-factor codes are never captured. A recovery tool that quietly saved passwords would be worse than the problem it solves.

FormKeep is free, open source, and has no accounts or paywall. If losing form entries is a recurring tax on your day, it is here: https://chromewebstore.google.com/detail/formkeep-automatic-form-r/gfladlcipgnehkhpakihjlheoohofmoc

It will not save you from every bad form. It does not sync between machines, and snapshots older than your retention setting (seven days by default) clean themselves up. What it does is turn the worst version of the problem, retyping twenty minutes of work from memory, into a two click recovery.