Skip to content

Is Vanilla CookieConsent enough for EU compliance?

Vanilla CookieConsent is a JavaScript library that can be used to build a cookie dialog. It is an example of a free open-source solution that can be useful for websites that want to build and maintain their own cookie and consent setup.

For websites that need to follow cookie rules and the GDPR in the EU and EEA, the important question is not only whether a cookie dialog can be shown. Cookie rules are based on the ePrivacy Directive and national legislation, while the GDPR becomes relevant when cookies or related scripts involve the processing of personal data.

The question is therefore not whether Vanilla CookieConsent can be used on a website. It can. The question is whether the library itself is enough as part of a solution where information, consent, documentation and follow-up need to work together.

A library can help with the dialog, but not the whole responsibility

Vanilla CookieConsent can help you build the browser-based consent interface. It can show choices, remember the visitor’s selection and let developers react to that selection in JavaScript.

That is useful, but it does not remove the website owner’s responsibility.

The website owner still needs to make sure that the information is correct, that scripts are conditioned against the right consent category, that cookies are not set too early, that consent can be changed or withdrawn and that the current setup can be reviewed over time.

For organizations that need to follow EU and European privacy requirements, these surrounding parts are often just as important as the dialog itself.

Cookie rules and the GDPR cover different parts

Cookie rules, which are based on the ePrivacy Directive and national legislation, govern when the website may set cookies. Necessary cookies can normally be set without consent, but the website owner still needs to inform the visitor that they are being set. For cookies that are not necessary, the website should wait for the visitor’s consent.

The GDPR becomes relevant when the use of cookies or related scripts involves the processing of personal data. When consent is used, the website owner also needs to be able to document and show that consent afterwards.

Consent needs to be possible to document

When consent is used as the legal basis, the website owner needs to be able to show that consent has been given.

A value stored only in the visitor’s browser can help the website remember the visitor’s choice. But it does not by itself give the website owner documentation that can be followed up afterwards.

For a consent solution to support EU compliance work, consent normally needs to be logged or documented in a way that the website owner can access later. That documentation should make it possible to understand what the visitor was asked, what choice was made and when the choice was made.

Building and operating that kind of documentation is a separate responsibility if it is not included in the solution.

The cookie list needs to reflect the real website

A compliant cookie setup depends on correct information.

The cookie list should describe the cookies the website actually uses. This includes cookies set by the website itself and cookies set through external services, plugins, embedded content, analytics tools, marketing tools and tag managers.

A JavaScript library does not automatically know when the website changes or when a new service starts setting cookies.

That means the website owner needs a routine for scanning, reviewing and updating the cookie list. Without that routine, the visitor may be shown outdated information even if the dialog itself still works.

Google Consent Mode needs to be handled where it is used

If the website uses Google Analytics, Google Ads or Google Tag Manager, the visitor’s choice may also need to be passed on as consent signals to Google.

That is not the same thing as only showing a cookie dialog.

If Google Consent Mode is not handled by the cookie solution, the connection between the visitor’s choice and Google’s consent signals needs to be built, tested and maintained separately.

That can work, but it becomes another part that the website owner needs to take responsibility for.

The visitor must be able to make and change a real choice

A consent solution should help the visitor understand what they are choosing.

That means the information should be clear, the choices should be understandable and it should be as easy to reject non-necessary cookies as it is to accept them.

The visitor also needs to be able to change or withdraw consent later.

This is important both for legal compliance and for trust. A cookie dialog should not only collect a click. It should support a conscious and informed choice.

Maintenance is part of the compliance work

A website changes over time.

New campaigns, plugins, tracking tools, embedded services and tag manager changes can introduce new cookies or new data flows. That means the cookie setup also needs to be maintained over time.

For a website that needs to follow EU and European privacy rules, the question is not only whether the cookie dialog worked when it was first implemented. The question is whether the setup continues to reflect how the website actually works.

If you use Vanilla CookieConsent, this maintenance needs to be handled by your own organization or by the agency or developer responsible for the implementation.

When can Vanilla CookieConsent be a reasonable choice?

Vanilla CookieConsent can be a reasonable choice if you want to build and maintain your own consent solution.

It can work well as a technical building block for organizations with the competence and routines needed to handle the surrounding requirements.

You should then make sure that you also have a solution for:

  • documenting consent
  • keeping the cookie list up to date
  • keeping the information shown to the visitor correct and understandable
  • handling cookies and scripts according to the visitor’s choice
  • handling Google Consent Mode where needed
  • allowing visitors to change or withdraw consent
  • reviewing the setup when the website changes

Without those parts, the library mainly solves the visible dialog. It does not by itself solve the full work required around cookies and consent.

Summary

Vanilla CookieConsent can be useful for building a cookie dialog.

But for websites that need to follow cookie rules and the GDPR in the EU and EEA, a cookie dialog is only one part of the solution.

The website owner also needs to make sure that cookies and scripts are handled correctly, that the visitor receives clear information, that consent is collected before it is needed, that consent can be documented, and that the setup is maintained when the website changes.

In that context, Vanilla CookieConsent should be seen as a technical component, not as a complete consent solution.

Do you need help reviewing your cookie banner?

CookieTractor helps you handle the cookie dialog, consent, cookie list, documentation and follow-up.

If you are unsure whether your current solution is enough for the requirements you need to consider in the EU or EEA, we can help you review how cookies, consent and scripts work on your website.

Feel free to contact us at info@cookietractor.com.