Cookie-Free Websites

When are cookies really necessary?

The widespread use of cookies is mostly due to technical setups that automatically include them, and not due to real technical necessity. Some functions traditionally use cookies because they are convenient, not because there is no alternative.

“Essential” cookies, in a strict technical sense, are primarily limited to situations where they are required to ensure the basic functionality of a service explicitly requested by the user. This typically includes maintaining a secure session during a login process, preserving the contents of a shopping cart within an ongoing transaction, or ensuring the integrity and security of communication, e.g. session identifiers for authenticated areas. Many other uses often labelled as “essential” are, in reality, based on convenience or implementation choices rather than strict necessity.

Login systems are one example. Many websites use cookies to keep users signed in and to identify their session across pages. In e-commerce, cookies are often used to maintain a shopping cart. Certain security measures may also rely on cookies, for example to distinguish valid requests from suspicious ones or to maintain a secure user session. In such cases, cookies may indeed be functionally necessary for that specific setup.

However, many other functions do not inherently require cookies. An example is a portfolio website with a lightweight backend, such as a contact form. This is a static website with text, images, locally hosted CSS, JavaScript and a simple contact form. In many cases, a setup like this is a perfectly sufficient solution for professionals such as consultants, lawyers, doctors or coaches. Even more complex features can be implemented without cookies if the way each function works and the real-life behaviour of third-party services is observed carefully. When designing more dynamic functions, cookies can sometimes be avoided if the developer does not rely on third-party tools, but uses server-side processing or local hosting instead.

For example, a feature which can function with or without cookies is external social media integration. If a website embeds Facebook or Instagram plugins directly, those services may load cookies or other tracking elements as soon as the page loads. That does not necessarily happen because the website itself needs cookies, but because the external platform does. By contrast, where a website is intended to remain cookie-free, sharing options can simply be implemented as links. In that case, no third-party cookies are loaded when the visitor opens the website. They may only be triggered after a further interaction, namely if the user actually clicks on the link. That often avoids the issue entirely.

Implementation of social media links instead of plugins

Another example concerns file downloads or script delivery. If a website uses external infrastructure such as certain content delivery or protection services, cookies may be introduced for performance or traffic management reasons. If the same files are hosted locally on the operator’s own server, the very same user-facing function may work without those cookies. This shows that cookies are often not about the visible feature, but about the technical path chosen to implement it.

We recently applied this approach ourselves when implementing a cookie-free ZIP file download on one of our platforms.

One important feature, relevant for many businesses, are analytics tools. These also frequently rely on cookies, especially where they are designed to identify returning visitors, measure behaviour over time or attribute traffic sources in detail.

However, analytics do not always require cookies. There are privacy-focused, cookie-free analytics approaches that collect only limited, aggregated or anonymised information. Some tools can be configured to avoid cookies entirely, and server log analysis can also provide useful insights without storing identifiers in the user’s browser. The trade-off is that cookie-free analytics may offer less detailed behavioural tracking, but for many websites that is not a disadvantage at all. Sometimes less data means less legal risk, less complexity and more trust.

The questions that arise from this analysis are understandable. Is it really necessary to inspect every single function manually and to observe the exact real-life behaviour of third parties? The answer depends on how much you value simplicity and compliance, but also on the point at which such an approach stops being economically viable. In practice, the better solution is to implement certain approaches once, understand them properly, and then repeat them securely across multiple websites.

Cookie use – benefits and risks

User convenience

Cookies do have advantages. They can improve convenience for users by remembering settings, keeping sessions active or enabling certain interactive functions. In some applications, they are a straightforward and established way to preserve information between page requests. That is one reason why they have been used so widely for so long.

Furthermore, in certain constellations, they can also support security-related functions. It would therefore be wrong to present cookies as inherently suspicious or automatically unlawful. They are first and foremost a technical tool. Whether their use is appropriate depends on what exactly they do, whether they are actually needed, and how transparently they are implemented.

Are cookies “bad” for privacy and security?

Cookies are not automatically “bad” for privacy and security. Technically, they are just small pieces of data stored in a user’s browser. In some cases, they serve practical purposes, such as remembering a login session or keeping a shopping cart active while the visitor moves through an online store. From a purely technical perspective, a cookie is only a tool.

To identify when a privacy problem may arise, it is important to keep in mind that legal expectations differ depending on the country or region. Within the EU, privacy and consent rules are generally stricter, especially regarding non-essential cookies. In other parts of the world, the legal approach may be more flexible, less harmonised or more focused on disclosure than on strict prior consent. This creates a practical problem for international websites: a setup that may seem acceptable in one jurisdiction can still create legal or reputational risks elsewhere. For that reason alone, some website operators prefer to reduce cookie use wherever possible.

In the UK and EU, it is particularly problematic where cookies are used to track users beyond what is technically necessary, especially without their knowledge and prior consent. Users must be given the possibility to provide freely given, specific, informed and unambiguous consent, and must also be able to withdraw that consent at any time with effect for the future.

This is particularly relevant with third-party cookies, which are placed not by the website the user intended to visit, but by external services loaded on that website. Third-party cookies can make it possible to follow users across multiple websites, build profiles of their interests and behaviour, and combine this information for advertising, analytics or other commercial purposes.

This often leads to transparency issues, as users have very little real overview of who receives their data, why it is collected and how long it is kept. Many websites use third-party scripts or plugins without the operator fully understanding what happens in the background. A social media plugin, embedded video, advertising tag, analytics script or content delivery service may set cookies before the user even meaningfully interacts with the page. Even where disclosures exist, they are often buried in cookie banners or privacy policies that few people read in detail. It is not uncommon for such information to be misleading or incomplete.

The issue is therefore not only whether cookies are used, but how, when and why they are used, and whether the user is given a real choice before any data is processed.

This is also where so-called dark patterns become relevant. A recent paper, When the Abyss Looks Back: Unveiling Evolving Dark Patterns in Cookie Consent Banners, describes large-scale evidence of manipulative practices in cookie banner design. The paper is based on an analysis of approximately 14,000 websites and finds that cookies are often set before consent, opt-out mechanisms frequently fail to prevent third-party tracking, and consent revocation is often obstructed rather than made easy.

The same study also points to concrete security implications. It reports that many cookies use insecure attributes, increasing exposure to attacks such as XSS and CSRF, and that websites exhibiting revocation barriers set about 25% more cookies on average. It further notes that a large share of observed cookies were long-lived, with many persisting for more than a year. This appears problematic, especially since regulators in some countries tend to view cookie durations beyond 12 months as excessive and potentially non-compliant.

For readers interested in the paper itself:

Singh, N./ Jin, S./ Kim, H.: When the Abyss Looks Back: Unveiling Evolving Dark Patterns in Cookie Consent Banners, submitted on 23 Mar 2026, arXiv:2603.21515

Even where cookies are used, their configuration matters. Missing or misconfigured security attributes can expose users to unnecessary risks. This is one of the reasons why cookies should not be treated as a purely formal consent-banner topic. They can also become a technical and security issue.

Do cookies slow down your website?

Strictly speaking, not really.

Cookies are small pieces of data that are sent with requests to the server, so their direct impact on loading speed is usually minimal. Even where several cookies are present, the extra data transfer is often negligible compared to images, scripts, fonts or other resources.

However, cookies rarely exist in isolation. In practice, they are often part of larger tracking, advertising or analytics setups that introduce additional scripts, external requests and background activity. These can affect how quickly a page becomes usable, even where the server itself responds very quickly. In that sense, cookies are usually not the actual performance problem. They are more often a sign of the kind of technical structure that can create one.

So the more accurate statement is not that cookies themselves “make websites slow”, but that cookie-heavy setups often come together with external dependencies and tracking logic that increase complexity and may negatively affect performance.

Practical thoughts for website owners and visitors

Who should build my website?

This depends on your needs. You can have a perfectly well-functioning and compliant website with cookies, provided that they are implemented properly.

Using a site-building tool may sometimes result in what we like referring to as “cookie soup” – an implementation in which significantly more cookies are used than necessary, the site owner has no real control over which cookies are used, when they are set, and whether the visitor has a meaningful opt-out option. The reason for this is not necessarily a malfunction of the site-building tool, but rather a structural mismatch between the technical components of the website and the way they were implemented.

However, there is another practical truth worth keeping in mind. A website built by a web designer and legal texts prepared by a lawyer do not automatically guarantee compliance with data protection requirements.

This does not necessarily mean that either of them did their job badly. The mismatch described above may also occur here. The lawyer may not fully understand the implementation details, and the web designer may not fully understand the legal consequences. The problem is that in such a situation, responsibility still remains with the site owner. Someone who understands both sides will either implement the setup very carefully or, in simpler cases, choose to avoid cookies altogether.

For simple portfolio websites, we generally prefer the second option for the reasons described above.

If you prefer a cookie-free website, contact us.

Do I need a cookie banner?

Not if you use no cookies at all, and not if you use only strictly necessary cookies and no other tracking technologies that require consent.

If a website does not use cookies and does not involve any consent-based tracking, then a cookie banner may not be legally necessary.

That said, some website operators still include a small notice for clarification. For example, they may state that the website does not use cookies or that it is designed to minimise data collection. That is not the same as asking for consent. It is simply a transparency measure that may reassure visitors and prevent confusion.

How can I check whether a website uses cookies?

There are simple ways to check. Many browsers already show in their settings whether cookies are present for a website. In some cases, you may see a small indication such as “1 cookie” or “3 cookies”.

A more useful method is to open the browser’s developer tools. In most browsers, you can do this by right-clicking on the page and selecting “Inspect”. Then look in sections such as “Application”, “Storage” or similar areas where stored site data is listed. There you can usually find a dedicated “Cookies” section showing which cookies exist, which domain placed them, and sometimes how long they remain active.

Final thought

Cookie-free websites are not only possible, but often beneficial where a simple static website is sufficient. The key question is not whether cookies are normal, but whether they are truly needed for the functions a website offers. In many cases, they are not.

A more privacy-friendly website often begins with a simple decision: use only what is necessary, host as much as possible locally, and avoid unnecessary third-party dependencies.

That approach can reduce legal complexity, improve transparency and create a cleaner experience for visitors. Sometimes the more modern solution is not adding more tracking technology, but removing what was never needed in the first place.