People asking about types of cookies are usually asking one of four different questions, and the answers cut across each other rather than nesting. A single cookie has a position in all four classifications at once, which is why a list that mixes them is so confusing to read. Sorting out which classification you need is the fastest way to make a cookie table coherent.
By who set it: first party and third party
Decided by whether the cookie's domain matches the site in the address bar. It is a pure domain test and says nothing about who wrote the code or who reads the value. This is the classification browsers act on, which is why it dominates technical discussions and why it has become less useful as measurement moved to first party storage set by third party scripts.
By how long it lasts: session and persistent
Decided by whether an expiry was set. Session cookies go when the browsing session ends; persistent ones survive until their date. This is the classification that appears in cookie tables as a lifetime column, and it is the one most often copied from vendor documentation rather than observed, which is how tables come to state lifetimes browsers never honoured.
By what it is for: the consent categories
Strictly necessary, functional, analytics or performance, and advertising or targeting. This is the classification your banner is built on and the only one a visitor is asked about. It is also the only one that is a judgement rather than a fact, which is why the reasoning behind each assignment is worth writing down beside it.
By what it holds: identifiers, preferences and state
A rougher classification but a useful one when deciding what to disclose, because it maps onto what a visitor would actually care about. An identifier that can be joined to a profile elsewhere is a different proposition from a flag saying a notice was dismissed, even when both are persistent first party cookies in the functional category.
Why your table should carry more than one
A cookie table with only the consent category is unauditable, because nobody can check the assignment. A table with name, domain, who set it, lifetime observed, purpose and category lets a reader verify the judgement rather than take it on trust, and it lets you answer the question a new tag raises without redoing the whole exercise. The extra columns cost one pass and save every later one. The other reason to keep the extra columns is that they make the table survive a change of consent platform. Vendor exports carry the vendor's own taxonomy, and a table that only records their category has to be rebuilt from scratch when you move. One that records domain, setter, observed lifetime and purpose can be re-categorised in an afternoon.
Questions people ask about types of web cookies
How many types of cookies are there?
It depends entirely on which classification you mean, which is why the question has so many different confident answers. Four classifications, each with its own small set.
Which type needs consent?
The consent categories decide it: everything except strictly necessary, regardless of where a cookie sits in the other three classifications.
Are secure and http-only types of cookie?
They are attributes rather than types, and they concern how the cookie is transmitted and whether scripts can read it. Worth setting correctly and not part of the consent question.
Is a supercookie a type?
It is a name for storage that resists deletion, usually not a cookie at all. Treat it as in scope for the storage rule and as a thing to remove rather than to categorise.
What type is the consent cookie itself?
First party, persistent, strictly necessary, and it holds state rather than an identifier. A tidy example of all four classifications at once.