Legal
GDPR and your reviews widget: what data it actually processes
A reviews widget sits in front of two separate rules, and almost every compliance checklist collapses them into one. Cookie consent comes from the ePrivacy Directive and is triggered by writing to the visitor’s device, while GDPR governs the processing of personal data and is triggered by the server calls the widget makes and the personal data it displays. A widget can therefore be entirely free of consent-banner obligations for storage and still raise a real GDPR question, because the reviews it renders are personal data about the people who wrote them. This post measures both halves on our own widget, with the numbers and the date, including the one cookie we do set.
The two rules, and why the order matters
Article 5(3) of the ePrivacy Directive is about storage. If a script stores information on the
visitor’s terminal equipment, or gains access to information already stored there, you need
consent unless the storage is strictly necessary to deliver a service the user explicitly asked
for. Cookies are the famous case, but the rule is technology-neutral: localStorage,
sessionStorage and device fingerprinting are all covered. Nothing in that article says anything
about whose data is displayed.
GDPR is about processing personal data, and it does not care whether anything was stored on the device. An HTTP request to a third-party server transmits the visitor’s IP address to whoever runs it, and an IP address is personal data. So a widget that stores nothing at all still causes processing the moment the browser fetches it, and that processing needs a lawful basis and a place in your privacy policy.
Getting the order right saves a lot of wasted effort. Storage questions are answerable by measurement in about ten minutes. Processing questions are answerable by reading what the vendor does with the request, and by asking who else the browser was made to talk to.
What our widget does on the page, measured
Everything below comes from an isolated test we ran on 2026-08-20: a blank page on our own origin, the widget script and stylesheet, no analytics, no tag manager, no other scripts. We loaded three widget types in a fresh browser context each time, waited for the reviews to render, then read the storage APIs and every network request the page made.
All three types behaved identically on load. document.cookie was empty. localStorage and
sessionStorage had zero keys. No new cookies appeared in the browser context, which catches
HttpOnly cookies that a page’s own JavaScript cannot see. The only hosts the browser contacted
were justreview.co for the script, stylesheet and fonts, and api.justreview.co for the
reviews themselves. No fourth host, on any of the three.
The API call is a single GET with no request body. Everything it carries sits in the URL path:
the account hash, the list of review sources to include, the widget type and a limit and offset
for paging. There is no field for the visitor, because the response does not depend on who is
reading the page. The response carried no Set-Cookie header and is cacheable for 24 hours,
which means a busy page often serves the reviews out of cache without reaching us at all.
Total weight was 202,286 bytes: a 128,526-byte script, a 15,585-byte stylesheet and three font files at roughly 19 KB each.
The one cookie, and exactly when it appears
We do set one cookie, and a post claiming otherwise would be false. The badge widget, the small
floating rating pill, has a dismiss button on mobile. If the visitor taps it, the badge writes
justreviewCookie=disableMobile as a first-party cookie on your domain, with a one-hour
expiry, and hides itself. That is the whole mechanism: a fixed string with no identifier in it,
set only in response to a deliberate click, so the badge stays out of the way for the rest of
the visit.
On load, before any interaction, the badge sets nothing. We confirmed that separately in the same test run. The other widget types have no cookie path in their code at all. If your consent tooling inventories cookies, this is the one line you need, and it is worth knowing that a user-requested UI preference is the textbook example of the storage the ePrivacy exemption was written for.
Self-hosted fonts matter more than they sound
Our three font files come from justreview.co/widget/fonts/, not from a font CDN. That looks
like a performance detail and is actually the single most common way a well-meaning widget
creates a legal problem for the site that embeds it.
A font loaded from a third-party CDN is an HTTP request from your visitor’s browser to that provider, which transmits the visitor’s IP address before any banner has been clicked. A Munich regional court decided in 2022 that a website embedding Google Fonts this way owed damages to a visitor for exactly that transmission, and the reasoning has been repeated in complaints across the EU since. The same logic applies to any asset a widget hotlinks: fonts, icon sets, stylesheets, avatars.
This is why “does it set cookies” is the wrong first question. A widget can be perfectly cookie-free and still make your visitor’s browser call four different companies before the page finishes painting.
What the visitor’s browser never contacts
The measured request list has a second consequence that is easy to miss: the widget rendered
zero <img> elements. Not zero external images, zero images.
Review platforms serve reviewer profile photos from their own image CDNs. A widget that displays those avatars by pointing at the original URL makes every one of your visitors send a request to Google or Facebook, which is the same IP-transmission problem as the fonts, multiplied by the number of reviews on screen. Our widget renders the source logos as inline SVG in the script itself, and it does not render reviewer avatars at all. The trade-off is honest: avatars make a testimonial section look busier and more human, and we do not show them.
What our server sees, and what we keep
Any HTTP request reveals the caller’s IP address to the server receiving it, and ours is no exception. Like every web server, ours writes access logs. The interesting question is what we keep in the product, and that is answerable from the schema.
The widget API records a hit in a table with exactly seven columns: a row ID, the account ID, the
domain the request came from, the date, a first-seen and last-seen timestamp, and a counter.
There is no IP column, no user-agent column, no visitor ID and no cookie ID, so there is nothing
in it that could be joined back to a person. The domain comes from the Origin or Referer
header and exists so that a customer can see whether their widget is actually live on their site.
The aggregation is not cosmetic. Across the 28 days to 2026-08-20, 296,227 widget API calls were recorded as 14,398 stored rows, covering 898 domains and 438 accounts. That is roughly 21 calls per row, and the busiest single row collapsed 738 calls from one site on one day into one record. A per-visitor log of the same traffic would have been 296,227 rows with something identifying in each of them.
The part nobody writes about: the reviewers
Everything above concerns your visitors. The harder GDPR question for any reviews widget concerns the people whose reviews you are republishing, because a review carries a name, an opinion and sometimes a photo, and that is their personal data sitting on your commercial website.
That question is about provenance, not about cookies. Where did the review come from, does the source permit republishing it, and can a reviewer get it taken down. We wrote about the republication side in is it legal to embed Google reviews and about how the reviews are collected in the docs on whether scraping reviews is legal. A widget with a spotless cookie report and a scraped-without-permission review set is the worse of the two problems, not the better one.
What a widget can process, and what ours does
Ordered by how much each item complicates your consent banner, heaviest first.
| What a widget can do | Why it matters | Ours, measured 2026-08-20 |
|---|---|---|
| Store a per-visitor identifier in a cookie or localStorage | Needs consent, and makes the widget a tracker | None on any of the three types |
| Load fonts, icons or avatars from a third-party CDN | Sends the visitor’s IP to that provider before consent | None, fonts self-hosted, zero images rendered |
| Fire analytics or ad pixels alongside the reviews | Separate processing, separate consent, separate vendor | No host contacted other than ours |
| Send visitor details in the API request | Turns a content fetch into profiling | Single GET, no body, no visitor field |
| Log every request per visitor server-side | Large personal-data store with retention duties | Aggregated per domain per day, no IP or UA column |
| Set a UI preference cookie on a deliberate click | Minor, but must be declared | One, badge only, one hour, disableMobile |
What is still your job
None of this is legal advice and none of it removes work from your side. You still name the widget vendor as a processor in your privacy policy, still keep a data processing agreement on file, and still declare that one badge cookie if your consent tool inventories cookies.
There is also a practical trap worth flagging, because we walked into it on our own website.
Consent platforms in automatic blocking mode classify scripts by origin, not by behaviour, so
they will happily block a widget that sets nothing. Our own landing pages ran Cookiebot in
auto mode, and it rewrote the widget script’s type attribute to text/plain on 5 of 8
measured visits, which meant our own product demo silently failed for most visitors. The fix
was an explicit ignore attribute after verifying in code that the script had nothing to consent
to. If your reviews disappeared the week you installed a consent banner, that is where to look.
Where JustReview stands
If the privacy footprint of a reviews widget is on your checklist, ours is the one you can verify yourself rather than take on trust: no cookie on load, no third-party host, self-hosted fonts, no hotlinked avatars, one aggregated row per site per day, and one documented preference cookie on the badge. Every number in this post came from a test you can repeat on a blank page in about ten minutes, which is the point of publishing them with a date attached.
You can see what the widget puts on a page on the Google reviews widget page, check what each plan includes on pricing, and create an account to run the same measurement against your own domain. If star ratings in search results are also on your list, the trade-offs there are in our post on review schema markup.
The caveats, stated plainly: we do set that one badge cookie, our access logs exist like anyone else’s, and a clean storage report says nothing about whether the reviews themselves were collected properly. That last question is the one worth spending your afternoon on.
FAQ
Does a reviews widget need cookie consent?
It depends on whether the widget writes anything to the visitor's device, not on whether it displays personal data. The consent requirement for cookies and similar storage comes from the ePrivacy Directive and applies to storage, so a widget that sets no cookie and touches neither localStorage nor sessionStorage does not create a storage-based consent obligation. That is a separate question from GDPR, which governs the processing of personal data and applies to the widget's server calls regardless of storage. Measure your widget rather than trusting the vendor's marketing page: open the page with only the widget on it, then read document.cookie and the network panel.
Is a reviews widget a third-party tracker?
Not automatically, and the distinction is technical rather than legal. A tracker keeps a per-visitor identifier so it can recognise the same person across requests or sites. A widget that fetches a public list of reviews with no identifier, writes nothing to the device and reports back only an aggregated per-domain counter has nothing to recognise anyone with. What makes many widgets trackers in practice is not the reviews, it is the extras bolted around them: analytics pixels, session recording, ad-network beacons and fonts or avatars pulled from a third-party CDN.
Do reviews shown in a widget count as personal data?
Yes, and this is the part most compliance checklists miss. A review carries the reviewer's name, their opinion and often a photo, which is personal data about that person, not about the visitor reading your page. So the GDPR question for a reviews widget is mostly about the reviewers, not the audience: where the reviews came from, whether the source permits republication, and whether a reviewer can get their review removed from your site. Answering the visitor-tracking question with a clean bill of health does not answer this one.