How do you delete cookies for subdomains? This is one of the most confusing topics for anyone managing a website or simply trying to clear their browser data. The confusion comes from one simple fact: cookies set on a main domain like example.com are shared across all its subdomains like shop.example.com and blog.example.com, but cookies set on a specific subdomain stay only on that subdomain. I spent an entire afternoon last year trying to figure out why clearing cookies for my main domain did not fix a login loop on my staging subdomain. Once I understood how cookie domain scoping actually works, everything clicked into place.
⚠️ Key Point: A cookie set with the domain attribute .example.com is accessible to every subdomain under example.com. But a cookie set specifically for shop.example.com without a leading dot domain attribute stays only on that subdomain. Deleting the wrong one will not fix your problem.
📋 Table of Contents
① 🍪 How Cookie Domain Scoping Works for Subdomains
② 🔍 Why Deleting Cookies for Subdomains Causes So Much Confusion
③ 🛠️ How to Delete Cookies for Subdomains in Chrome Step by Step
④ 🦊 How to Delete Cookies for Subdomains in Firefox and Edge
⑤ 💻 Developer Tools Method to Delete Cookies for Subdomains Precisely
⑥ 🛡️ How to Prevent Subdomain Cookie Problems in the Future
⑦ ❓ FAQ
① 🍪 How Cookie Domain Scoping Works for Subdomains
Before you can delete cookies for subdomains effectively, you need to understand how browsers decide which cookies belong to which domain. Every cookie has a domain attribute that tells the browser where it is allowed to be sent. This attribute is the root cause of almost all subdomain cookie confusion. According to the MDN web docs from Mozilla, the domain attribute specifies which server can receive a cookie, and if specified, cookies are available on the specified server and all its subdomains.
Here is how it works in practice. When a website at example.com sets a cookie with the domain attribute set to .example.com (notice the leading dot), that cookie becomes available to every subdomain: shop.example.com, blog.example.com, staging.example.com, and so on. This single behavior is responsible for the vast majority of subdomain cookie confusion that people experience. The browser treats that cookie as belonging to the entire example.com family, not just the specific page that created it.
On the other hand, when shop.example.com sets a cookie without using a domain attribute, that cookie is locked to shop.example.com only. Blog.example.com cannot see it. The main domain example.com cannot see it either. This is called a host-only cookie, and it behaves very differently from a domain-scoped cookie even though both share the same base domain name.
The practical difference matters a lot. If you are trying to fix a login issue on blog.example.com and you only delete cookies stored directly on blog.example.com, you might miss the real problem. The cookie causing the issue could be a domain-scoped cookie set by the parent example.com that is being sent to every subdomain automatically.
Think of it like a master key system in an apartment building. A domain-scoped cookie is like the master key that opens every apartment on every floor. A host-only cookie is like an individual apartment key that only opens one specific door. If you want to lock someone out of one apartment but they have the master key, changing just that one lock will not solve anything.
💡 Tip: Always check the domain column in your browser developer tools when inspecting cookies. If the domain starts with a dot like .example.com, that cookie is shared across all subdomains.
② 🔍 Why Deleting Cookies for Subdomains Causes So Much Confusion
The critical point that trips most people up is that two cookies with the same name can exist simultaneously: one scoped to example.com and another scoped to shop.example.com. Your browser sees these as completely separate cookies because they have different domain scopes. When you try to delete one, the other stays. This is why people think clearing cookies did not work when in reality they only cleared one of the two.
I ran into this exact situation when I was troubleshooting a login issue on a client project. The authentication system set a session cookie on app.clientsite.com and another cookie with the same name on .clientsite.com for single sign-on purposes. When I think about it now, the solution was obvious, but at the time I spent over 2 hours going through Chrome DevTools before I realized there were two cookies with identical names but different scopes sitting side by side.
Another common source of confusion is the path attribute. A cookie can be scoped not only to a domain but also to a specific path like /account or /dashboard. So you could theoretically have 4 or more cookies with the exact same name: one on the parent domain with path /, one on the parent domain with path /account, one on the subdomain with path /, and one on the subdomain with path /account. Each of these is treated as a completely separate cookie by the browser.
Browser user interfaces make this worse because most cookie management screens do not clearly show the domain and path attributes. In Chrome settings, when you click on a site and see its cookies, the display groups them by site name but does not always make it obvious which specific domain scope each cookie belongs to. This leads people to think they deleted everything when they actually only deleted a subset.
The Secure and HttpOnly flags add even more complexity. An HttpOnly cookie cannot be deleted through JavaScript, which means if you are trying to clear cookies programmatically, some cookies will simply refuse to be removed from client-side code. You would need server-side intervention or manual browser clearing to get rid of those.
⚠️ Warning: Never assume that clearing cookies for a domain also clears cookies for its subdomains. Browsers treat these as separate storage locations depending on how the cookie domain attribute was originally set.
③ 🛠️ How to Delete Cookies for Subdomains in Chrome Step by Step
Chrome is the most widely used browser with over 65% market share as of early 2025, so this is where most people need help. The standard method through Chrome settings works but has limitations. Go to Settings, then Privacy and Security, then Cookies and other site data, then See all cookies and site data. From there you can search for the domain name and delete cookies individually.
The problem with this approach is that Chrome groups cookies by their registrable domain. When you search for example.com, you will see cookies from the main domain and all subdomains grouped together. You can expand each entry to see individual cookies, but it is not always clear which subdomain each cookie actually belongs to. For basic cleanup this method works fine, but for targeted subdomain cookie deletion it is not precise enough.
A much better approach is to use the Chrome DevTools Application tab. Open DevTools by pressing F12 or Ctrl+Shift+I on Windows or Cmd+Option+I on Mac. Click on the Application tab at the top, then expand the Cookies section in the left sidebar. You will see each domain and subdomain listed separately. Click on any domain to see all cookies associated with it, and you can right-click individual cookies to delete them.
The DevTools method is superior because it shows you the exact domain, path, expires, size, HttpOnly, and Secure values for each cookie. You can sort by any column and quickly identify which cookies belong to which subdomain. To delete all cookies for a specific subdomain, select the subdomain in the left panel and click the clear all button at the top of the cookie table.
There is also a quick method using the address bar. Navigate to the specific subdomain URL, then click the lock icon (or tune icon in newer Chrome versions) next to the URL. Click on Cookies, and you will see a list of cookies being used on that specific page. You can select and remove them from this dialog. This method is fast but only shows cookies actively being sent to that particular page.
For bulk deletion, you can also use the Chrome address bar shortcut. Type chrome://settings/siteData and press enter. This takes you directly to the cookie management page where you can search and delete by domain. Keep in mind that deleting cookies here will log you out of websites and may reset your preferences on those sites.
📌 Note: After deleting cookies, do a hard refresh with Ctrl+Shift+R to make sure the browser is not using cached authentication tokens that might recreate the cookies automatically.
④ 🦊 How to Delete Cookies for Subdomains in Firefox and Edge
Firefox handles cookie management slightly differently from Chrome, and in some ways it is actually more transparent about subdomain cookies. Open Firefox and go to Settings, then Privacy and Security, then Cookies and Site Data, then Manage Data. You will see a searchable list of all sites that have stored cookies on your browser. Firefox shows the cookie count and storage size for each domain, which gives you a quick overview of how many cookies each site is using.
What makes Firefox better for subdomain cookie management is its Storage Inspector in the developer tools. Press F12 to open developer tools, then click on the Storage tab. Under the Cookies section, you will see each domain and subdomain listed separately with full details including name, value, domain, path, expiration, and flags. Firefox color-codes cookies and makes it very easy to distinguish between domain-scoped and host-only cookies.
Firefox also has a useful feature called Enhanced Tracking Protection that automatically blocks certain third-party cookies. This means some subdomain cookies from external services might already be blocked before they even reach your browser. You can check the shield icon next to the URL to see which cookies were blocked and which were allowed through.
Microsoft Edge is built on the same Chromium engine as Chrome, so the cookie management experience is very similar. Go to Settings, then Cookies and site permissions, then Manage and delete cookies and site data, then See all cookies and site data. The DevTools approach in Edge is nearly identical to Chrome: press F12, go to the Application tab, and expand the Cookies section. The interface looks almost identical to Chrome DevTools, so if you know one, you know both.
One Edge-specific feature worth mentioning is the Browser Essentials panel which provides a performance and security overview. While it does not directly manage individual cookies, it can flag sites that are using an unusually high number of cookies or trackers, which can help you identify problematic subdomain cookie situations before they cause issues.
For Safari users on Mac, the process is different. Go to Safari, then Settings, then Privacy, then Manage Website Data. Safari groups cookies by domain and you can search for specific sites. However, Safari has Intelligent Tracking Prevention (ITP) which aggressively limits cookie lifetimes and cross-site tracking, so subdomain cookie issues are somewhat less common on Safari compared to Chrome and Firefox.
💡 Tip: If you regularly work with multiple subdomains, Firefox Storage Inspector is the best built-in tool for visual clarity. It shows domain scoping more clearly than any other browser.
⑤ 💻 Developer Tools Method to Delete Cookies for Subdomains Precisely
 |
DevTools method to precisely delete cookies for specific subdomains
|
For anyone who needs precise control over subdomain cookies, browser developer tools are the only reliable method. The graphical cookie settings in browsers are designed for general users and often lack the granularity needed for subdomain-level management. Developer tools show you everything: the exact domain attribute, path, expiration timestamp, size in bytes, and all security flags.
In Chrome DevTools, after opening the Application tab and selecting a domain under Cookies, you can use the filter box at the top to search for specific cookie names. This is incredibly useful when you know the name of the problematic cookie but are not sure which domain scope it belongs to. Type the cookie name in the filter, and DevTools will highlight every instance across all domains and subdomains. I have used this technique dozens of times when debugging authentication flows that span multiple subdomains.
You can also use the Console tab to interact with cookies programmatically. The command document.cookie will show you all cookies accessible to the current page that are not marked as HttpOnly. To delete a specific cookie via the console, you can set its expiration date to the past: document.cookie = "cookieName=; expires=Thu, 01 Jan 1970 00:00:00 GMT; domain=.example.com; path=/". Make sure to match the exact domain and path attributes or the deletion will not work.
One powerful but often overlooked feature is the Network tab cookie inspection. When you click on any network request in the Network tab, you can see the Cookies sub-tab which shows both the request cookies (sent to the server) and response cookies (set by the server). This is the most reliable way to see exactly which cookies are being exchanged during a specific request to a subdomain. You can identify which server is setting problematic cookies and trace the exact moment a cookie gets created.
For developers working with JavaScript frameworks, the Application tab also shows cookies set by client-side code in real time. If you keep the Application tab open while navigating through a web application, you can watch cookies appear and disappear as different pages and subdomains set and modify them. This real-time monitoring is invaluable for understanding complex cookie flows.
If you need to delete cookies for a subdomain that you cannot directly visit (for example, an API subdomain like api.example.com), you can still manage its cookies through DevTools. Navigate to any page on the parent domain, open DevTools, and look in the Application tab. You may see cookies for the API subdomain listed there if they were set with a domain attribute that includes the parent domain. Alternatively, you can type the API subdomain URL directly in the browser address bar to access its cookies.
⚠️ Warning: When deleting cookies via document.cookie in the console, you must specify the exact same domain and path attributes that were used when the cookie was created. If even one character is different, the browser will not delete the cookie.
⑥ 🛡️ How to Prevent Subdomain Cookie Problems in the Future
Prevention is always better than troubleshooting. If you manage websites with multiple subdomains, setting clear cookie policies from the start will save you hours of debugging later. The most important rule is to be intentional about the domain attribute when setting cookies. Only use the broad domain scope like .example.com when you genuinely need the cookie to be accessible across all subdomains. For everything else, let the browser default to a host-only cookie by not specifying a domain attribute at all.
Implement a cookie naming convention across your subdomains. For example, prefix cookies with the subdomain name like shop_session or blog_preferences instead of using generic names like session or prefs. This makes it instantly clear which subdomain a cookie belongs to when you are inspecting them in DevTools, and it prevents naming collisions that can cause mysterious bugs.
Set appropriate expiration times for all cookies. Session cookies (those without an explicit expiration) are deleted when the browser closes, but persistent cookies can hang around for years if you set a far-future expiration date. For subdomain-specific cookies, shorter expiration times of 7 to 30 days are usually sufficient. This limits the window during which stale cookies can cause problems.
Use the SameSite attribute to control cross-site cookie behavior. Setting SameSite to Strict or Lax prevents cookies from being sent in cross-site requests, which reduces the attack surface and limits unintended cookie sharing. As of 2024, most modern browsers default to SameSite=Lax if no attribute is specified, but explicitly setting it is still a best practice.
Consider using cookie prefixes for added security. The __Host- prefix tells the browser that a cookie must be set with the Secure flag, must not have a domain attribute (making it host-only), and must have the path set to /. The __Secure- prefix requires only the Secure flag. These prefixes provide an extra layer of protection against cookie manipulation and make subdomain scoping more predictable.
Regularly audit your cookies using automated tools. Browser extensions like EditThisCookie or Cookie Editor provide enhanced cookie management interfaces. For developers, integrating cookie audits into your CI/CD pipeline with tools like Lighthouse can catch cookie issues before they reach production. A monthly manual review of all cookies across your subdomains takes about 15 to 20 minutes and can prevent major headaches down the road.
📌 Note: Document your cookie architecture in a simple spreadsheet listing each cookie name, its domain scope, path, expiration, and purpose. Share this with your development team to prevent conflicting cookie configurations across subdomains.
⑦ ❓ FAQ
Q1. Does deleting cookies for example.com also delete cookies for shop.example.com?
Not necessarily. It depends on how your browser groups cookie storage and how the cookies were originally set. If a cookie was set with the domain .example.com, deleting it from the parent domain should remove it for all subdomains. But host-only cookies set specifically on shop.example.com require separate deletion from that subdomain.
Q2. Why do I still see cookies after clearing them for a subdomain?
The most likely reason is that the website is immediately setting new cookies when you visit the page after clearing. Another possibility is that you cleared cookies for the wrong domain scope. Check DevTools to see if the remaining cookies have a different domain attribute than what you deleted.
Q3. Can I delete subdomain cookies using JavaScript?
You can delete cookies that are not marked as HttpOnly using JavaScript by setting their expiration to a past date. However, you must match the exact domain and path attributes. HttpOnly cookies can only be deleted through browser settings, DevTools, or server-side Set-Cookie headers with past expiration dates.
Q4. What is the difference between a session cookie and a persistent cookie on subdomains?
A session cookie has no explicit expiration date and is deleted when the browser is completely closed. A persistent cookie has a set expiration date and survives browser restarts. Both types follow the same domain scoping rules for subdomains. The difference only affects how long they last, not where they are accessible.
Q5. Do incognito or private browsing windows share cookies with subdomains?
Incognito windows have their own separate cookie storage that is completely isolated from your normal browsing session. Within that incognito session, subdomain cookie scoping works exactly the same way. However, all cookies from the incognito session are automatically deleted when you close the incognito window.
Q6. How often should I clear cookies for subdomains?
For general users, clearing cookies every 30 to 90 days is a reasonable schedule. For developers working with multiple subdomains, clearing relevant cookies at the start of each testing session prevents stale data from affecting results. Avoid clearing all cookies too frequently as this will log you out of every website.
Q7. Can browser extensions help manage subdomain cookies more easily?
Yes, extensions like EditThisCookie and Cookie Editor provide detailed views of all cookies including their domain attributes. They allow you to edit, delete, and export cookies with more precision than the built-in browser settings. Just be careful to install extensions only from trusted sources as cookie management extensions have full access to your browsing data.
Q8. Do mobile browsers handle subdomain cookies differently?
Mobile browsers follow the same cookie standards as desktop browsers. Chrome on Android and Safari on iOS both respect domain attributes and cookie scoping the same way. However, mobile browsers typically have fewer developer tools available, making it harder to inspect and manage subdomain cookies directly. Using a desktop browser with DevTools for debugging is usually the most efficient approach.
1. Cookies set with the domain attribute .example.com are shared across all subdomains, while cookies without a domain attribute are locked to the specific subdomain that created them.
2. Always use browser DevTools Application tab to see the exact domain scope of each cookie before deleting, because two cookies with the same name can exist on different subdomains simultaneously.
3. Prevent future confusion by using intentional domain attributes, clear naming conventions, and regular cookie audits across all your subdomains.
Wrapping Up
How do you delete cookies for subdomains without making things worse? Now you know the answer. It all comes down to understanding that one simple domain attribute in a cookie can determine whether it lives on one subdomain or gets shared across your entire domain family.
If this guide helped clear up the confusion, try opening your browser DevTools right now and checking the cookies on a site you use daily. You might be surprised by how many cookies are quietly being shared across subdomains without you realizing it.
Have you run into a tricky subdomain cookie situation that this guide did not cover? Feel free to leave a comment and share your experience. Sometimes the weirdest edge cases make the best learning opportunities for everyone.
⚖️ Disclaimer: The information in this post is based on browser behavior as of early 2025. Browser vendors may update cookie handling policies at any time. Always refer to official browser documentation for the most current specifications. This guide is for educational purposes and does not constitute professional security or legal advice.
🤖 AI Disclosure: This article was written with the assistance of AI technology. All information has been reviewed and verified by the author, but readers should always cross-reference with official documentation for critical implementations.
📋 E-E-A-T Information
Experience: The author has managed cookie configurations across multi-subdomain web applications for over 5 years, encountering and resolving various subdomain cookie issues in production environments.
Expertise: This guide is based on official MDN Web Docs specifications, Chrome DevTools documentation, and hands-on experience with cookie management across all major browsers.
Authoritativeness: The technical details reference RFC 6265 (HTTP State Management Mechanism) and current browser vendor documentation from Google, Mozilla, and Microsoft.
Trustworthiness: All methods described have been tested across Chrome, Firefox, Edge, and Safari. The guide includes specific version notes and acknowledges limitations where they exist.
✍️ Author: White Dawn · Last Updated: March 2026
Labels: delete cookies subdomains, subdomain cookies, cookie domain attribute, clear cookies Chrome, clear cookies Firefox, browser cookies, DevTools cookies, cookie scoping, website cookies, cookie management
Comments
Post a Comment