HardwareTestingPro
Home / System Tools / Cookies Enabled Test

Cookies Enabled Test

This tool actually writes a real test cookie and reads it back - a genuine functional check, not just a browser-reported flag that could be wrong in edge cases.

Check Browser Cookie Support

FIRST-PARTY COOKIE DIAGNOSTICSChecking context
Running cookie checks…

Creating temporary cookies, checking exact values and cleaning up.

Browser-reported settingChecking
Functional same-site cookie testChecking
JS-visible cookies after cleanupChecking

Cookie attribute checks

One test at a time · no account data shown
What this can verify: A temporary cookie was accepted and immediately read in this page. Reading a cookie back does not independently prove its Secure/SameSite rules for cross-site requests, server storage or future persistence.

Privacy: Test cookie values are random non-personal tokens. Tests run locally with document.cookie, delete their own cookies immediately; a session cookie may remain until the browser session ends if cleanup fails. No external test endpoint is contacted. Cookies can be included in subsequent matching HTTP requests while present; existing cookie names/values are never shown or exported.

★ ★ ★ ★ ★
No ratings yet — be the first

What Is a Cookies Enabled Test?

A cookies enabled test checks whether this page can use JavaScript-readable, first-party browser cookies. It is more useful than relying on navigator.cookieEnabled alone: the tool creates a short-lived random test token, reads its exact value with document.cookie, and then deletes it. A successful test describes only the current page and browser context, not every other website or embedded third-party service.

How to Use the Cookies Enabled Test

  1. Open this page: the first-party cookie check starts automatically. Look for the main result marked Verified Here, Works · Warnings, or Not Verified.
  2. Compare the two indicators: the browser-reported navigator.cookieEnabled value and the actual write/read result. If they disagree, trust the specific observed readback rather than assuming all cookies are enabled or disabled.
  3. Review each attribute check: session, SameSite=Strict, optional HTTPS-only Secure combinations, short Max-Age and cookie deletion. Not Tested is expected for HTTPS-only options on HTTP.
  4. Check cleanup: the delete row should say Cleaned. The visible cookie count is only the number of cookies this page can read after cleanup, not all browser cookies.
  5. Repeat or export: use Run Test Again after changing browser privacy settings. Copy Summary or Download JSON saves status and limitations without exposing existing cookie names or values.

How It Works

The page first reads the browser's cookie-enabled flag. Then it attempts short-lived first-party cookie writes using document.cookie with different attributes. Every test uses a unique, non-personal token, checks for an exact name/value match, and immediately attempts deletion using the same cookie path. The expiry check also verifies that Max-Age=0 makes a recently written cookie unreadable. No external network test is made by this widget. However, a cookie may be included in a later matching HTTP request while it exists, which is how browser cookies normally work.

Reading a cookie back verifies write/read availability, but JavaScript cannot inspect its stored Secure, SameSite, or HttpOnly attributes directly. These attribute checks report local acceptance, not a complete cross-site or server-request security audit.

Understanding Your Results

  • Verified Here: the basic first-party session cookie was written and read back successfully, and no other tested operation failed.
  • Works · Warnings: basic cookies are readable, but an additional attribute check or cleanup step failed. Look at the individual rows instead of treating this as a global cookie block.
  • Not Verified: the page could not read back its own temporary cookie. Browser policy, context restrictions, extensions or document settings may explain the failure.
  • Not Tested: an HTTPS-only test was intentionally skipped on HTTP. This does not mean a secure cookie failed.
  • JS-visible count: counts cookies readable via document.cookie in the current document; it excludes HttpOnly cookies, other sites and cookies outside accessible paths.

Browser Limitations

This page runs as a first-party test on the current website. It cannot establish whether a third-party iframe on another website is allowed to access unpartitioned cookies or whether tracking prevention, partitioning or storage access rules will permit a future cross-site request. SameSite=None; Secure being accepted in a first-party page is not proof that third-party cookies work. An accepted Max-Age value is also not proof a cookie will survive a browser restart, and this tool does not test server-set HttpOnly cookies. Privacy modes may still allow temporary session cookies.

Common Mistakes to Avoid

  • Equating navigator.cookieEnabled with a full diagnostic: it is a useful browser hint, but actual set/read behavior can differ by context.
  • Assuming a Secure or SameSite readback proves network enforcement: the tool cannot see the attributes in JavaScript; verifying cross-site delivery requires an appropriate server-side setup.
  • Treating the cookie count as the number of cookies on the device: it is only a limited, JavaScript-visible count for the current document.
  • Expecting all private browsing to disable cookies: many browsers still permit session-only cookies during a private session.
  • Calling a skipped HTTPS check a failure: a skipped test means it was not meaningfully attempted in that context.

Frequently Asked Questions

Why test this instead of just checking navigator.cookieEnabled?

Because the flag is a browser-reported setting. Writing a temporary cookie and reading back its exact value directly checks whether this document can use JavaScript-readable first-party cookies.

Does the test cookie stay on my device after the test?

The tool deletes each cookie after attempting to read it and checks cleanup. If deletion cannot be confirmed, it shows a warning; test cookies are assigned short lifetimes where applicable. Like any cookie, a successful write is still temporary browser state until it is deleted.

Is the test cookie sent to any server?

The widget makes no extra network request to test cookies. Browser cookies can be attached automatically to subsequent matching HTTP requests while they exist; the tool does not guarantee that no request can occur during the brief test. It never exports or displays existing cookie names or values.

Why does my test fail in private/incognito mode?

Private modes differ between browsers. Some allow first-party temporary cookies, while specific privacy settings, extensions or embedded contexts can limit writes or reads. A private-session result is not a permanent-storage test.

What should I do if cookies are actually disabled?

Review the browser's cookie/privacy settings, website permissions and content-blocking extensions. Try a normal top-level HTTPS tab, then run the test again. The Web Storage Test can separately check local and session storage.

Conclusion

A real set/read/delete test is stronger evidence of first-party cookie availability than a flag alone. The detailed results explain where support is confirmed, limited, skipped or uncertain—without claiming to measure every third-party or server-side cookie policy. To check other storage mechanisms, see the Web Storage Test.