Paste Cookie or Set-Cookie headers and see each cookie’s flags, scope and security risks, in your browser.
Cookies drive sessions, preferences and tracking, and their flags determine how secure they are. This inspector splits each cookie from Cookie (request) or Set-Cookie (response) headers, shows the name, decoded value, domain, path and lifetime, and evaluates the security flags: Secure, HttpOnly, SameSite, Partitioned and the __Host- and __Secure- prefixes. For each cookie it lists concrete risks, such as sessions without HttpOnly (exposed to XSS), SameSite=None without Secure (rejected by browsers) and oversized cookies. It also detects values that look like a JWT or Base64. Everything runs locally, with no requests made.
A cookie starts simple, a name=value pair, but what decides whether it is safe are the attributes that ride along with Set-Cookie: Secure, HttpOnly, SameSite, Domain and Path, plus the __Host-/__Secure- prefixes and the Partitioned attribute. The Cookie header, sent by the browser in the request, carries none of those flags, only the name=value pairs, which is why full security analysis needs the response's Set-Cookie.
The inspector reads each pasted cookie and checks the attributes against the rules browsers actually enforce: SameSite=None without Secure is rejected, an invalid __Host- prefix makes the browser drop the whole cookie, and Partitioned without Secure is rejected too. None of this is theoretical, it is documented behavior in current browsers.
Example 1, SameSite=None alone is not enough. A cookie that needs to be sent in a cross-site context (e.g. a widget embedded on another site) requires SameSite=None, but without the Secure flag current browsers reject the whole cookie. The correct combination is SameSite=None; Secure.
Example 2, the myth of the leading dot in Domain. For a long time, Domain=.example.com (with a leading dot) looked like the only way to apply a cookie to every subdomain, while Domain=example.com (no dot) looked more restricted. That changed: the current cookie specification ignores the leading dot, so any explicit Domain value already covers the domain and all its subdomains. Only omitting the Domain attribute restricts the cookie to the exact host (host-only).
For a response's Set-Cookie, open DevTools (Network › click the request › Response Headers). For cookies already stored in the browser, use DevTools › Application › Cookies, that table can be copied and pasted directly, the inspector recognizes the tab-separated format. For a request's Cookie header, check Network › Headers on the request.
The limit is intentional: the tool does not read your browser's document.cookie or make any requests, it only analyzes the text you paste. That avoids exposing cookies from other tabs or sites without you noticing, and it means the tool never needs to reach a server to fetch headers, which would open an SSRF hole. Also remember that real session cookies are credentials, avoid pasting them on shared or untrusted machines.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/cookie-inspector"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="Cookie Inspector"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
Set-Cookie is sent by the server in the response to define a cookie, with all its flags (Secure, HttpOnly, SameSite, etc.). Cookie is sent by the browser in the request and only carries name=value pairs, with no flags. That is why full security analysis is only possible on Set-Cookie cookies.
Paste in any format: Set-Cookie, a Cookie header, name=value, or copied from DevTools (Application tab), including tab-separated. Each format is detected automatically.
The tool splits each cookie, reads its security flags and flags risks like missing Secure, HttpOnly and SameSite. Nothing leaves your browser.
For security, this tool does not access any site or use the server as a proxy (which would expose the server IP and SSRF holes). You paste the cookies and all analysis runs locally. Do not paste real session cookies on computers that are not yours.