Paste Set-Cookie headers (or a Cookie request header) and see what browsers really do: accepted or rejected and exactly why, the stored scope — domain, path, expiry after the 400-day cap — SameSite behavior, __Host- rules, size limits, and whether the cookie would accompany a given request. The acceptance model is tested against real Chrome and curl, not just the RFC. Cookies often carry live session credentials; nothing you paste leaves your browser.
A cookie is rejected outright — not fixed, dropped — if it contains a control byte, if name+value exceed 4096 bytes, if SameSite=None lacks Secure, if a __Host- name breaks its rules (Secure, no Domain, Path=/), or if its Domain doesn't cover the setting host. An oversized attribute (over 1024 bytes) is dropped silently while the cookie survives — usually changing its scope. Expiry is capped at 400 days no matter what you ask for; a date in the past is a deletion order. Cookie dates are their own dialect: token order is free, months are names, seconds are mandatory, timezones are ignored. And Domain=site.example doesn't restrict the cookie — it broadens it to every subdomain; the tightest cookie has no Domain at all.