Cookie Jar
Resonance maintains a local cookie jar that automatically captures cookies from responses and injects them into matching requests — the same behaviour as a browser, without any server or cloud storage involved. Cookies are scoped per environment so your development and production sessions never mix.
How It Works
- When a response includes a
Set-Cookieheader, Resonance parses and stores it locally - On each subsequent request, Resonance checks the jar and injects a
Cookieheader for all cookies whose domain, path, and flags match the request URL - All matching follows RFC 6265 — domain matching, path matching,
Secure,HttpOnly,SameSite, expiry, andMax-Ageare all respected - Expired cookies are pruned automatically before each request
Environment Scoping
Cookies are stored per active environment. Switching from Development to Production in the environment selector also switches to that environment's cookie jar — no cross-contamination between sessions.
- If no environment is active, cookies are stored under a default bucket
- Clearing cookies in one environment has no effect on others
Enabling and Disabling
The cookie jar is enabled by default. To toggle it, open the Cookie Manager and use the switch at the top of the dialog. When disabled, Resonance neither captures nor injects cookies — useful when testing endpoints that rely on explicit auth headers rather than session cookies.
Cookie Manager
Open the Cookie Manager from the toolbar to inspect and manage all stored cookies for the active environment.
What you can see
DomainThe domain the cookie is scoped to.NameThe cookie name.ValueThe cookie value. Hidden (••••••) for HttpOnly cookies.PathThe path scope — only requests under this path receive the cookie.ExpiresSession for cookies without an expiry; a timestamp for persistent cookies.FlagsActive attributes: HttpOnly, Secure, SameSite=<value>.Actions
- Search — filter by domain, name, or value
- Delete — remove a single cookie
- Clear session cookies — remove all cookies without an expiry date
- Clear all — remove every cookie for the active environment
Cookie Attributes
Resonance parses and honours the following Set-Cookie attributes:
DomainIf set, subdomain matching applies. If absent, the cookie is host-only (exact match only).PathCookie is only sent on requests whose path starts with this value. Defaults to /.ExpiresAn absolute expiry date. Cookies past this date are pruned automatically.Max-AgeExpiry in seconds relative to now. Takes precedence over Expires. Max-Age=0 deletes the cookie immediately.HttpOnlyStored and injected normally; value is masked in the Cookie Manager UI.SecureOnly injected when the request URL uses https:.SameSiteStored and displayed as a flag; informational only in the context of a desktop client.Common Scenarios
Session-based authentication
Send a login request. If the server responds with a Set-Cookie: session=… header, Resonance stores it. All subsequent requests to that domain automatically include the session cookie — no manual header needed.
Switching environments
Log in against Development, switch the environment selector to Staging, and send the same login request there. Each environment holds its own cookies. Switching back to Development restores the previous session.
Inspecting what was set
After sending a request, open the Cookies tab in the response panel to see the raw Set-Cookie headers. Open the Cookie Manager to see the parsed, stored result.
Disabling for a specific test
When testing an endpoint that expects no cookie (e.g. to confirm an unauthenticated response), disable the jar in the Cookie Manager, send the request, then re-enable it.
Next Steps
- Getting Started — request basics, environments, and authentication
- Using Scripts — access
response.cookiesin test scripts to inspect cookies programmatically - Collection Runner — cookie state is shared across all steps in a run