0
Not analyzed
Run the checker to evaluate cookie security.
Cookie Security Checker
Inspect Secure, HttpOnly, SameSite, Domain, Path and expiration settings across one or more Set-Cookie headers.
Paste one or more Set-Cookie values, or enter a public website URL to inspect cookies returned by the server.
✓
No cookies were set — that is a clean result
This response carried no Set-Cookie header at all.
- URL checked
- —
- HTTP status
- —
- Cookies in the response
- 0
What this means
Nothing is wrong and nothing failed. A response with no cookies is the strongest
possible result for the checks this tool runs — there is no cookie that could
be missing Secure, missing HttpOnly, or set to
SameSite=None. Under GDPR and the ePrivacy Directive, setting no
non-essential cookie before consent is the behaviour that is actually required.
Why a site you expected cookies from might show none
- Nothing has happened yet. Most sites create a session only once you log in, add something to a basket, or submit a form.
- The consent banner has not been answered. A compliant site holds its analytics and advertising cookies back until you accept them — and this check never clicks anything.
- The page is static or CDN-cached. A cacheable response cannot carry a per-visitor
Set-Cookie, so edge-served pages usually have none by design. - Cookies are set later by JavaScript.
document.cookiewrites never appear in a response header, so this check cannot see them. Your browser's DevTools → Application → Cookies can. - The server answered a bot differently. Some sites skip session setup for automated requests.
Worth trying next
🍪
Cookies Found
0
Set-Cookie headers
🔒
Secure
0
HTTPS-only cookies
🙈
HttpOnly
0
blocked from JavaScript
🧭
SameSite Set
0
cross-site policy defined
⚠️
High-Risk Cookies
0
important weaknesses
✓
Strong Cookies
0
recommended protections
⏳
Persistent
0
Expires or Max-Age set
🌍
Broad Domain
0
shared across subdomains
🔎 Security Findings
💡 Recommended Improvements
🧾 Normalized Cookie Headers
🌐 Source Information
HOW IT WORKS
Manual Analysis in Your Browser, Live Checks From Our Server
Pasting Set-Cookie header values and analyzing them for Secure, HttpOnly, SameSite, prefix and expiration rules happens entirely in your browser - nothing is sent anywhere. Checking a live website is different: browsers deliberately hide the Set-Cookie response header from cross-origin JavaScript, so our .NET backend fetches the page instead and reads the raw Set-Cookie headers directly off the HTTP response (never a comma-merged approximation). The same SSRF protections used across our security tools apply here too - private, loopback, link-local and cloud-metadata addresses are always rejected, and every redirect hop is re-validated before being followed. The backend never stores or logs the cookie values it reads, and only response headers are fetched - the page body is never downloaded.
Related tools: Security Headers Checker · CSP Checker · CORS Checker
Cookie Security Checker FAQ
Why does SameSite=None without Secure matter?
Modern browsers reject cookies marked SameSite=None unless they also have the Secure flag, so this combination usually means the cookie will silently fail to be set at all - a functional bug as much as a security one.
What do the __Host- and __Secure- prefixes do?
These are browser-enforced naming conventions: a __Host- cookie must have Secure, no Domain attribute, and Path=/, while a __Secure- cookie must have Secure set. Browsers reject a Set-Cookie header that uses the prefix without meeting its rules.
Can I check an internal or private site's cookies?
No. Hostnames that resolve to localhost, private IP ranges, link-local addresses or cloud metadata endpoints are rejected before any request is made, and each redirect hop is re-validated the same way.
Does the backend store the cookies it reads?
No. Cookie values pass straight through the response and are never written to logs or storage - only the exception message is logged if a fetch fails, never response content.
Why does the tool disable normal cookie handling when fetching a site?
By default, .NET's HTTP client would quietly absorb Set-Cookie headers into its own cookie store instead of surfacing them - and would carry cookies between requests. This tool disables that entirely so each check is stateless and the raw headers are always returned.
