 Third-party cookies are just browser cookies like any other, but they're set by a site that's different from the top-level page. For example, your site might include a third-party widget in an iFrame that sets a cookie to save preferences. Or maybe your site includes images from an image server. You know, it's run by your own company, but it's on its own domain. Now even though you run both the website and the image server, cookies from the image server across sites. So they're still treated like third-party cookies. Chrome is planning to deprecate third-party cookies, so you need to act now to ensure a smooth transition. I'm Sam Dutton, a developer advocate with the Chrome team, and in this video I'll show you how to check cookie usage on your site. You'll learn how to identify third-party cookies and work out where they're coming from. And in the next video in this series, you'll find out how to test your site without third-party cookies to check for breakage. You should begin by auditing cookie usage on your sites with your browser developer tools. Now in this video, I'll use Chrome DevTools, but other browsers have great DevTools as well. So the obvious place to start is the Network panel. In Chrome DevTools, click on an item and select the Cookies tab to show the cookies for a request. In this case, we're looking at cookies for the homepage HTML. Now request cookies are cookies that have already been set, which are sent with a request. There are Google Analytics cookies here, and a cookie for language and localization preferences. The response cookies are the cookies the server is asking the browser to set. And again, you can see Google Analytics cookies. As with the request cookies, both of these are set from Web.dev, the same site as the top-level page. And you can see the same cookies from the headers tab. For request headers and response headers. Alternatively, you can view cookies from the cookies pane of the application panel. Now this lists cookies by origin rather than by network request. And here you can see the cookies set for the origin, hdbsweb.dev. So that's how you can find cookie information, but how do you actually find third-party cookies? Well, because third-party cookies are being deprecated, you need to audit your site to find out where third-party cookies are being set and then plan a strategy to avoid breakage. Like I said earlier, third-party cookies are just cookies, but they're set for a site that's different from the current top-level page. So how do you find them? Well, in fact, when we talk about third-party cookies, we actually mean cookies that are set for any site that's different from the top-level page. And that might include cookies from your own sites, you know, not just from third-party services. So really, you need to look for cross-site cookies. Now, one simple trick is to check the same-site cookie value. The same-site attribute of a set cookie header can be set by a server to specify when the cookie will be sent. Same-site equals strict means the browser will only send the cookie for responses to same-site requests. Same-site equal lax means that the cookie won't be sent for cross-site requests, but it will be sent when a user navigates to the cookie's origin site, for example, you know, following a link. Same-site equals lax is the default behavior if the same-site attribute is not specified. Now, here's the thing. Cross-site cookies must be marked as same-site equals none. Secure, otherwise they won't be sent. And this means that you can find cross-site cookies by checking for cookies that have a same-site equals none value. And here you can see that there are no same-site equals none cookies for the web.dev HTML doc. And the cookies are all set by the domain web.dev. But if you look at the request for analytics iframe, you'll see that the NID cookie is same-site equals none. And the domain is .google.com. Now, likewise for other cross-site requests. You can open a file in a new tab, by the way, if you're trying to work out what it's used for. In this case, the included file is a recapture used by web.dev. In the response cookies same-site column for the analytics iframe, you'll notice an I in a circle. Now, as it says in DevTools, this means that same-site equals none wasn't specified for a cross-site cookie. So the same-site value defaulted to lax, and so the cookie was blocked. Now, one thing to bear in mind here is that you might see cookies being marked as same-site equals none, even when they're not used in a cross-site context. Now, that might be deliberate because the cookies are used elsewhere in a cross-site context. However, same-site equals none may have been set inadvertently. So you should check for unnecessary same-site equals none usage. And you can find out more from our same-site cookie recipes on web.dev, and you can learn more about the same-site attribute from our article, Same-site Cookies Explained. Another way to find third-party cookies is to check the cookies from the application panel. This lists cookies by the origin of the frame where they're used. You can see the cookies used by web.dev and then cookies used in other frames. None of these has a same-site value set, meaning the same-site value will be the default value of lax. For cookies in other frames, you can see same-site values. For example, for the NID cookie I mentioned before, you can see a same-site equals none value has been set. You can also see the requests that include a cookie. Three docs and two JavaScript requests include the NID cookie. Now, you can also see the domain for the cookie. By default, this is the origin that sets the cookie, but the domain cookie attribute controls if that cookie should be sent to sub-domains as well. For the NID cookie, the cookies domain attribute is Google.com. Now, you can click on the checkbox, only show cookies with an issue to highlight cross-site cookies. In fact, perhaps the easiest way of all to check for cross-site cookies is to use the Chrome DevTools Issues tab. Click the Open Issues Warning button that's next to Settings in the top right corner of the Action bar, or alternatively, select Issues from the More Tools menu. Now, if you want, you can reload the page or open other pages to find additional issues. And make sure that Include Third-Party Cookies Issues is checked. Click on the Cookie Warning Issue to see cross-site requests for cookies. That identifies cookies set with the value same-site equals none and secure, but not partitioned. In other words, the Chrome DevTools Issues tab lists cookies that will be affected by its Third-Party Cookie deprecation. Now, just in case you're wondering about partitioned cookies, cookies marked partitioned are double-keyed, you know, by the origin that sets them as well as the origin of the top-level page. And partitioned cookies, also known as chips, will not be blocked by Third-Party Cookie Deprecation. You should consider partitioning cookies for use cases such as cross-site embeds. And you can find out more about chips from our article on developer.chrome.com. Anyway, getting back to cookie issues, from the cross-site cookie warning, you can find out information about problematic cookies and the requests for which the cookies are set. And here you can see our old friend, the NID Cookie, which has the domain Google.com and is set on multiple requests. You can click on a request to open it in the network panel. So that's how you can use Chrome DevTools to find cross-site cookies, their domains, and the requests for which they're set. To find out more about identifying the sources of Third-Party Cookies on your site, take a look at our article on developer.chrome.com. Preparing for the end of Third-Party Cookies has everything you need to know about testing and deprecation timeframes, as well as strategies to help you transition smoothly from Third-Party Cookies to other technologies. To learn about testing how your site will perform after Third-Party Cookie Deprecation, take a look at the next video in this series, test your site without Third-Party Cookies. Thanks for watching and be sure to catch the other videos in our Third-Party Cookie Deprecation series.