Chrome Cookie Tricks for Debugging Authentication Without Creating Test Accounts

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over. There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts. I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening. 1. Simulate a Logged-Out State Without Clearing Everything The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up. The targeted approach: identify and delete only the session/auth cookie. Most session cookies are named session, sid, auth_token, _session_id, or something close. In DevTools: Application → Cookies → [your domain] → find the session cookie → right-click → Delete With CookieJar: open the extension, search session, click the trash icon next to just that cookie. Your dev environment stays intact. The user state resets to logged-out. 2. Test the "Returning User" vs "New User" Path Without a Second Account Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before. Look for cookies like onboarding_complete, setup_done, first_visit, or custom flags in your app code. To test the new user experience: Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools) Delete the specific onboarding/first-visit flag cookie Reload and test the new user path Re-import or re-set the cookie to restore your state This is especially useful when testing progressive disclosure UI — the "have they done X before" branching. 3. Switch Between User Roles Instantly with Cookie Snapshots If your app uses role-based access control, you'll regularly need to verify that: Admin users see the admin dashboard Regular users see the regular dashboard Guest users see the right landing page Creating three accounts and logging in/out manually wastes time. The better approach: cookie snapshots. Setup (one time): Log in as admin → CookieJar → Export → save as admin-session.json Log in as regular user → Export → save as user-session.json Log in as guest or clear auth cookies → Export → save as guest-session.json Switching roles (30 seconds): CookieJar → Import → load admin-session.json → reload You're now the admin. Test what you need. Import user-session.json → reload. Now you're the regular user. This works because the server trusts whoever holds the session token. You're not bypassing auth — you're using valid sessions you legitimately created. ⚠️ Keep these JSON files local and out of version control. They're valid session tokens. 4. Debug "Expired Session" Behavior by Manually Expiring a Cookie Testing what happens when a session expires is annoying. You either wait for it to actually expire (hours), or you mess with your server-side expiry logic. The clean way: manipulate the cookie's expiry date directly. In DevTools: Application → Cookies → your domain → double-click the Expires column of your session cookie → set it to a past date With CookieJar: click the cookie → edit the Expiry field → set it to yesterday → save. Reload the page. The browser now treats the session as expired, and you see exactly what the user sees when their session times out — login redirect, expired session message, or partial UI state. Reset by importing your saved session snapshot or logging in normally. 5. Find Which Cookie Is Causing a Redirect Loop Login redirect loops (/login → /dashboard → /login → ...) are almost always caused by a stale or malformed session cookie. The session exists but fails server-side validation. Systematic isolation approach: Open CookieJar and look at all cookies for the looping domain Note every auth-related cookie (look for names containing session, token, auth, jwt) Delete one at a time, reloading after each deletion When the loop stops (either you get logged out cleanly or it works), you've found the culprit This is much faster than clearing all cookies, because it tells you which cookie is broken — useful information for filing a bug report or understanding what's happening server-side. A common cause: the cookie domain or path is set incorrectly (e.g., set to .example.com but the app is at app.example.com). CookieJar shows you the full cookie metadata including domain, path, Secure, HttpOnly, and SameSite flags — exactly what you need to diagnose this. What About HttpOnly Cookies? HttpOnly cookies can't be read or modified by JavaScript, which is the right security choice for session tokens. But Chrome DevTools (and extensions with the cookies permission, like CookieJar) can still see and modify them — because the extension operates at the browser level, not the JavaScript level. So these techniques work even for HttpOnly session cookies. The Underlying API If you want to do this programmatically (in a test script or CI setup), the chrome.cookies API handles all of this: // Get all cookies for a domain const cookies = await chrome.cookies.getAll({ domain: 'localhost' }); // Delete a specific cookie await chrome.cookies.remove({ url: 'http://localhost:3000', name: 'session' }); // Set a cookie with a specific expiry await chrome.cookies.set({ url: 'http://localhost:3000', name: 'session', value: 'your-valid-session-token', expirationDate: Math.floor(Date.now() / 1000) + 3600 // expires in 1 hour }); For Playwright or Puppeteer testing, you can inject cookies directly into the browser context: // Playwright await context.addCookies([{ name: 'session', value: 'test-session-token', domain: 'localhost', path: '/' }]); // Puppeteer await page.setCookie({ name: 'session', value: 'test-session-token', domain: 'localhost' }); Tools Referenced Chrome DevTools (built in) — Application tab, manual cookie editing CookieJar — free Chrome extension for cookie editing, import/export, and privacy scoring. Built on MV3, stores everything locally. The cookie snapshot workflow (tip #3) is the one I use most. Set it up once, switch user roles in under 30 seconds for the rest of the project.

14 hours ago

5 Cookie Tricks for Debugging Auth Issues in Chrome (No More Creating Test Accounts)

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over. There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts. I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening. 1. Simulate a Logged-Out State Without Clearing Everything The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up. The targeted approach: identify and delete only the session/auth cookie. Most session cookies are named session, sid, auth_token, _session_id, or something close. In DevTools: Application → Cookies → [your domain] → find the session cookie → right-click → Delete With CookieJar: open the extension, search session, click the trash icon next to just that cookie. Your dev environment stays intact. The user state resets to logged-out. 2. Test the "Returning User" vs "New User" Path Without a Second Account Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before. Look for cookies like onboarding_complete, setup_done, first_visit, or custom flags in your app code. To test the new user experience: Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools) Delete the specific onboarding/first-visit flag cookie Reload and test the new user path Re-import or re-set the cookie to restore your state This is especially useful when testing progressive disclosure UI — the "have they done X before" branching. 3. Switch Between User Roles Instantly with Cookie Snapshots If your app uses role-based access control, you'll regularly need to verify that: Admin users see the admin dashboard Regular users see the regular dashboard Guest users see the right landing page Creating three accounts and logging in/out manually wastes time. The better approach: cookie snapshots. Setup (one time): Log in as admin → CookieJar → Export → save as admin-session.json Log in as regular user → Export → save as user-session.json Log in as guest or clear auth cookies → Export → save as guest-session.json Switching roles (30 seconds): CookieJar → Import → load admin-session.json → reload You're now the admin. Test what you need. Import user-session.json → reload. Now you're the regular user. This works because the server trusts whoever holds the session token. You're not bypassing auth — you're using valid sessions you legitimately created. ⚠️ Keep these JSON files local and out of version control. They're valid session tokens. 4. Debug "Expired Session" Behavior by Manually Expiring a Cookie Testing what happens when a session expires is annoying. You either wait for it to actually expire (hours), or you mess with your server-side expiry logic. The clean way: manipulate the cookie's expiry date directly. In DevTools: Application → Cookies → your domain → double-click the Expires column of your session cookie → set it to a past date With CookieJar: click the cookie → edit the Expiry field → set it to yesterday → save. Reload the page. The browser now treats the session as expired, and you see exactly what the user sees when their session times out — login redirect, expired session message, or partial UI state. Reset by importing your saved session snapshot or logging in normally. 5. Find Which Cookie Is Causing a Redirect Loop Login redirect loops (/login → /dashboard → /login → ...) are almost always caused by a stale or malformed session cookie. The session exists but fails server-side validation. Systematic isolation approach: Open CookieJar and look at all cookies for the looping domain Note every auth-related cookie (look for names containing session, token, auth, jwt) Delete one at a time, reloading after each deletion When the loop stops (either you get logged out cleanly or it works), you've found the culprit This is much faster than clearing all cookies, because it tells you which cookie is broken — useful information for filing a bug report or understanding what's happening server-side. A common cause: the cookie domain or path is set incorrectly (e.g., set to .example.com but the app is at app.example.com). CookieJar shows you the full cookie metadata including domain, path, Secure, HttpOnly, and SameSite flags — exactly what you need to diagnose this. What About HttpOnly Cookies? HttpOnly cookies can't be read or modified by JavaScript, which is the right security choice for session tokens. But Chrome DevTools (and extensions with the cookies permission, like CookieJar) can still see and modify them — because the extension operates at the browser level, not the JavaScript level. So these techniques work even for HttpOnly session cookies. The Underlying API If you want to do this programmatically (in a test script or CI setup), the chrome.cookies API handles all of this: // Get all cookies for a domain const cookies = await chrome.cookies.getAll({ domain: 'localhost' }); // Delete a specific cookie await chrome.cookies.remove({ url: 'http://localhost:3000', name: 'session' }); // Set a cookie with a specific expiry await chrome.cookies.set({ url: 'http://localhost:3000', name: 'session', value: 'your-valid-session-token', expirationDate: Math.floor(Date.now() / 1000) + 3600 // expires in 1 hour }); For Playwright or Puppeteer testing, you can inject cookies directly into the browser context: // Playwright await context.addCookies([{ name: 'session', value: 'test-session-token', domain: 'localhost', path: '/' }]); // Puppeteer await page.setCookie({ name: 'session', value: 'test-session-token', domain: 'localhost' }); Tools Referenced Chrome DevTools (built in) — Application tab, manual cookie editing CookieJar — free Chrome extension for cookie editing, import/export, and privacy scoring. Built on MV3, stores everything locally. The cookie snapshot workflow (tip #3) is the one I use most. Set it up once, switch user roles in under 30 seconds for the rest of the project.

1 day ago