🍪 Cookies Lab
Work through each section below, then check your browser's DevTools to see exactly what happened. That's how QA engineers inspect cookies on real projects.
The banner that appeared when you first loaded this page is a real cookie consent overlay. Practice accepting, rejecting, and dismissing it — then verify the result in DevTools.
Try It
Clears the consent cookie so you can practice the banner scenarios again.
Current Consent State
Live — reflects the real cookie_consent value on this page.
After interacting with the banner above, follow these steps to find the cookie your browser just stored.
How To Inspect
This section is read-only — nothing to execute. Create or delete cookies using Section 3, then watch them appear live on the right. For the full DevTools walkthrough (Domain, Path, Expires, HttpOnly, Secure — fields document.cookie cannot see), open Learn More → Chrome DevTools below.
Current Browser Cookies
Live — every cookie readable via document.cookie on this page.
| Name | Value | Delete |
|---|
For Domain, Path, Expiry and HttpOnly flags — use DevTools (above) or context.cookies() in your Playwright test.
Find it in DevTools
Press F12 to open DevTools
Or right-click anywhere on the page → Inspect
Click the Application tab
It may be hidden under the >> overflow menu at the top
In the left sidebar: Storage → Cookies → the current website
You will see the real cookie with every field:
This is the real cookie view. Domain, Path, and Expires are all visible here — fields that document.cookie in JavaScript cannot see. In Playwright, context.cookies() gives you the same complete picture.
Create a real cookie and verify it directly in DevTools.
Create Cookie
Submitting the same name again updates the value — the browser never creates duplicates.
Current Browser Cookies
Live — updates immediately after you set a cookie on the left.
Name and Value are read live from document.cookie — exactly what this page's own JavaScript can see. Domain / Path / Expires / Secure / HttpOnly / SameSite are never exposed to page JavaScript by the browser; they require DevTools or Playwright's context.cookies() (see Learn More).
| Name | Value | Domain | Path | Expires | Secure | HttpOnly | SameSite |
|---|
Session Cookie
Leave Expiry blank
DevTools Expires: empty
Deleted when tab closes
Persistent Cookie
Expiry: 3600 or 86400
DevTools Expires: future date
Survives tab close
Sign in through the app's own login form and watch the dashboard unlock live.
Login Through The Application
- Click the button below — a login form opens without leaving this page
- Sign in with the training account — a unique session token is generated
- The modal closes and the dashboard unlocks immediately
- Inspect the new cookie in DevTools to see the generated token
After login the session token appears in the dashboard above. Follow the steps in Section 2 to inspect it in DevTools — you will see Domain, Path, and Expires fields that document.cookie cannot read.
Execution Result
Live — the real dashboard state below, driven entirely by session cookies.
Admin Control Dashboard
Unlockedpw_session_token is httpOnly — invisible to document.cookie and the inspector table below. Check DevTools → Application → Cookies to see it, or use context.cookies() in Playwright.
✓ Login Successful — dashboard unlocked
Admin Control Dashboard
LockedPath 1 — Login Through the Application
Skip the login form entirely — write the session cookie directly, the same way Playwright's context.addCookies() or a DevTools console command would.
Inject Session Cookie
Click Inject Cookie to write pw_session_token directly via document.cookie — no login form, no server round-trip. The dashboard on the right unlocks purely because the cookie is present, which is itself the point: client-side checks like this one can be satisfied without ever calling the login API.
Open Orders PageUse this page to observe how authentication behaves before and after a session cookie exists. It initially shows "Login required" — after injecting a valid token and refreshing, the protected content appears.
Execution Result
Not injected yet.
How browser cookie authentication actually works:
cookies-lab.html's own dashboard skips step 5 deliberately (it checks cookie presence client-side, no server round-trip) — see Path 2 on the left for why that matters.