Will this cookie be stored, and where will it travel
Enter the name and value with SameSite, Secure, HttpOnly, Domain, Path and Max-Age, and the tool says whether a browser stores or rejects the cookie and writes the Set-Cookie header. Leaving SameSite out means it is treated as Lax, so the cookie rides a link click from another site but is not sent with subresource requests such as images or iframes.
The combinations that end in rejection are clear. SameSite=None requires Secure, and without it the cookie is rejected. Secure is HTTPS only, so an http: page cannot use it and therefore cannot use None either. A name starting with __Host- needs Secure and Path=/ and cannot carry a Domain. The sending conditions are in the table below, as of October 2026.
The verdict looks only at the attributes you entered. Browser settings, extensions, third-party cookie blocking and partitioned cookies are not modelled, so real traffic can be blocked more often. Values are not encoded here, so encode anything containing spaces or semicolons before entering it.
Frequently Asked Questions
It is treated as Lax. Older browsers behaved as if None was set and sent the cookie everywhere, which is no longer true. If subresource requests need the cookie, you have to write None together with Secure.
None requires Secure, and without it the browser rejects the cookie outright. Nothing is stored, so nothing rides the next request.
A Secure cookie travels over HTTPS only, so an http: page cannot set Secure, and None requires Secure. Serving your local test over HTTPS is the quicker fix.