In any event it is obviously important that the site does in the end get the cookie, because a reminder wouldn't really be worth much unless it is given. Equally, storing cookies is of no use unless they are replayed to the server which issued them.
Like the Set-Cookie: header, the Cookie: header is another very simple statement and looks as follows:
That is it. There is nothing else to it. It is an additional header, here constituting 17 bytes of data!
In the context of the other headers coming form a browser request it may look as follows
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20100714 SUSE/3.5.11-0.1.1 Firefox/3.5.11
Again I will not go into the specifics of the other headers but to point out that, like the Cookie: header, they are all information sent from the browser to the server letting the server know how best to respond to the browser.
The actual decision to send a cookie or not is mostly made at the time the cookie is initially accepted by the browser (if it was accepted it will likely be replayed). But each new request will check both the expiry (has the cookie expired - don't send) and the path (is the request to a location on the server where this cookie is permitted).