How to edit cookies in Chrome

TL;DR: To edit cookies in Chrome, open DevTools (F12) → Application → Cookies, then double-click any cell to change value, expiry, SameSite, HttpOnly, or Secure flags. For a faster workflow without DevTools, install CookieVault Editor and edit cookies inline from the toolbar popup. Both methods modify the cookie store immediately.

Editing cookies in Chrome is a browser operation that lets you modify the value, expiration, domain, path, and security flags of any cookie stored for a given site. The primary use cases are debugging session bugs, testing per-flag behavior (SameSite, Secure, HttpOnly), reproducing user-reported issues, and extending session lifetimes during development. Chrome provides two reliable methods — the built-in DevTools Application panel and a Manifest V3 extension — each suited to different workflows¹.

Quick comparison: DevTools vs extension

In short: DevTools is built in and requires no installation but demands multiple clicks per edit. An extension offers a faster, repeatable workflow from the toolbar — especially when editing cookies across multiple domains or making the same change repeatedly.

The Chrome DevTools Application panel documentation describes the cookie table as “an editable spreadsheet” for inspecting and modifying cookies during development¹. For production debugging and QA workflows that involve repeated edits, an extension reduces the number of steps per edit from six to two.

Method 1: Chrome DevTools (the built-in path)

In short: DevTools gives you direct access to every cookie attribute in a table format. Double-click any cell to edit. The change applies to the cookie store immediately — reload the page to see the server-side effect. Eight steps from opening DevTools to verified edit.

The eight-step DevTools cookie editing workflow:

1. Open the target website — navigate to the site whose cookies you want to edit. The cookies must already exist in your browser’s store for that domain.
2. Open Chrome DevTools — press F12 (or Ctrl+Shift+I on Windows/Linux, Cmd+Option+I on Mac). You can also right-click anywhere on the page and choose “Inspect.”
3. Navigate to the Application tab — click “Application” in the DevTools top bar. If the tab is not visible, click the chevron (>>) to expand the overflow menu.
4. Expand Cookies in the left sidebar — under “Storage,” expand “Cookies.” You will see the main domain plus any third-party domains that set cookies on this page.
5. Click the target domain — the main panel displays a table showing Name, Value, Domain, Path, Expires, Size, HttpOnly, Secure, SameSite, and Priority.
6. Double-click any cell to edit — the cell becomes an input field. Change the value and press Enter. Editable fields include Value, Expires/Max-Age, Domain, Path, SameSite, Secure, and HttpOnly.
7. Press Enter to commit — the cookie store updates immediately. No confirmation dialog; no undo.
8. Reload the page to verify — press F5. The site now receives the modified cookie on the next request. Confirm the expected behavior.

Important: Editing the Name field does not rename the cookie — it deletes the old cookie and creates a new one with the new name. If you only want to change the value, leave the Name field untouched.

Method 2: CookieVault Editor (extension)

In short: CookieVault Editor provides a toolbar popup with inline editing — click a cookie, change a field, click Save. No DevTools required. The extension uses Chrome’s chrome.cookies API, which means it can edit HttpOnly cookies and access cookies for any domain, not just the current page.

The eight-step extension workflow:

1. Install CookieVault Editor — install from the Chrome Web Store. The extension requests the cookies and tabs permissions needed to read and write cookies.
2. Navigate to the target site — open the site whose cookies you want to edit.
3. Click the toolbar icon — the popup lists all cookies for the current domain, grouped by first-party and third-party.
4. Click a cookie name — the detail view opens, showing Value, Domain, Path, Expires, SameSite, Secure, HttpOnly, and Size.
5. Edit the fields — change any field inline. SameSite, Secure, and HttpOnly are toggle switches. Expires has a date picker. Value is a text input.
6. Click Save — the extension writes the updated cookie via chrome.cookies.set(). The change applies immediately.
7. Verify — reload the page or observe the network panel to confirm the modified cookie is sent with the next request.
8. Optional: export before editing — for irreversible sessions (banking, admin panels), export to JSON first. If the edit breaks your session, import the backup to restore.

The extension workflow is particularly efficient for QA engineers who need to edit cookies on dozens of test domains per day, or for developers testing SameSite behavior across multiple origins.

Common cookie editing scenarios

In short: The most frequent reasons to edit a cookie are extending a session, testing SameSite behavior, simulating a different user, and debugging CSRF token mismatches. Each scenario maps to a specific field edit.

Six practical scenarios where editing cookies is the right debugging technique:

• Extend a session during debugging — double-click the Expires cell and set a date far in the future (e.g., one year from now). This prevents the session from expiring while you step through code. Useful when debugging long multi-step forms.
• Test SameSite behavior — change SameSite from Lax to Strict to verify that cross-site navigation breaks authentication as expected. Change to None (with Secure = true) to confirm cross-origin iframe embedding works.
• Simulate a different user — copy a session cookie value from one browser profile and paste it into another. This reproduces the exact session state without re-authenticating. Only works if the server does not bind sessions to IP or User-Agent.
• Debug CSRF token mismatches — CSRF tokens are often stored in cookies (csrftoken, XSRF-TOKEN). Editing the cookie value to a known-bad value confirms that the server rejects the request, validating CSRF protection.
• Force a cookie to Secure-only — set the Secure flag to true on a cookie and verify that the site breaks when loaded over HTTP. This confirms that the site handles the Secure flag correctly in mixed-content scenarios.
• Test cookie path scoping — change the Path from / to /admin and verify that the cookie is no longer sent on requests to /dashboard. This validates path-scoped cookie behavior.

Editable cookie attributes reference

In short: Chrome exposes eight editable attributes per cookie. Each attribute controls a different aspect of when, where, and how the cookie is sent. Understanding them is essential for effective debugging.

The Chromium project enforces a limit of approximately 180 cookies per domain. When this limit is reached, Chrome evicts cookies in order of Priority (Low first, then Medium, then High), and within each priority level by least-recently-accessed timestamp².

Limitations and edge cases

In short: Some cookie edits are constrained by browser security policies. Understanding these limits prevents wasted debugging time.

• Cross-origin cookies — you cannot edit cookies for a domain that has not set a cookie on the current page (in DevTools). Use an extension for cross-domain access.
• Partitioned cookies (CHIPS) — Chrome’s partitioned cookies feature means the same cookie name can have different values depending on the top-level site. Editing one partition does not affect the others.
• Server-side validation — changing a session cookie’s value to an arbitrary string will fail server-side validation. The server treats the modified value as an invalid session and issues a new cookie on the next response.
• Cookie size limits — a single cookie cannot exceed approximately 4,096 bytes (name + value combined). DevTools will silently truncate values that exceed this limit.
• __Host- and __Secure- prefixes — cookies with these name prefixes are subject to additional restrictions. A __Host- prefixed cookie must have Secure = true, Path = /, and no Domain attribute. Editing these attributes to violate the prefix rules causes Chrome to reject the cookie.
• Third-party cookie deprecation — as Chrome phases out third-party cookies, editing third-party cookies in DevTools may show warnings or have no effect for sites enrolled in the Privacy Sandbox.

See also

• How to delete cookies in Chrome — remove cookies entirely instead of editing them
• How to export Chrome cookies to JSON — backup cookies before editing as a rollback path
• Clear cookies but stay logged in — selective deletion while preserving sessions
• Auto-delete cookies on tab close — automated cleanup for privacy
• CookieVault Editor — the open-source Manifest V3 cookie editor for Chrome
• What is a cookie? — the underlying HTTP cookie protocol explained