What Google’s ad code receives when you read your Spotify file here.

Quilore is free because it carries advertising, and the advertising comes from Google. That means a script from Google loads on every page of this site, including the one that reads your export. It runs inside the page, in the same tab as the code that turns your file into statistics.

So “the ad network never sees your data” is not something the design guarantees on its own. A script in the page could, in principle, read what the page shows. The only honest way to make that claim is to watch what actually leaves the browser, so we did.

How we checked

1. A file nobody could confuse with real data. A synthetic export of 420 plays by three invented artists, with invented track and album titles. None of those names exists anywhere else, so any request containing one can only have got it from the file.
2. A browser that hides nothing. Chrome with a fresh profile, driven through its own debugging protocol, recording every request the page made, including requests from inside Google’s embedded frames and the body of anything sent.
3. The real page. quilore.com/upload, with the file chosen through the same button a visitor uses, and thirty seconds for the statistics, the charts and the album art to finish.
4. A search, not a skim. Every request, decoded, checked for each artist name, each track and album title, a play length from the file and the file’s own name.

First, proof the search could find something

A check that cannot succeed proves nothing, so before reading the result for Google we looked for the one place the names are supposed to go. Quilore fetches album art from Deezer’s public catalogue by artist and album name, as the privacy page says. The capture showed exactly that: three requests to Deezer, each carrying one of the invented artist names.

The method sees a name leaving when a name leaves. That is what makes the next result mean something. It also turned up something the privacy page did not yet mention, a cookie Deezer sets on those requests, which it now names. The album art switch on the results page stops any further lookups, and we confirmed that the same way: with it off, the Songs, Artists and Albums tabs sent Deezer nothing.

What Google received from the file

Nothing. The page made 13 requests to five Google hosts during the capture. None of them contained an artist, a title, a play length or the file name. None had a body. None carried a cookie, though a fresh profile had no Google cookies to send, so your own browser may differ on that point. After the file was read, the only requests Google’s code made were checks that belong to its ad traffic quality system, and those carried nothing from the file either.

What Google received anyway

The file stayed put, but the visit did not go unseen. Every request shows Google your IP address, and in that first capture one of the 13 was a request for an ad, with 65 parameters attached. We cannot vouch for what every one of them means, because Google does not publish the list. These are the ones whose values matched something we could check on the machine that ran the test.

The page address stops at /upload/. Once your results are showing, the address bar ends in #/stats, and even that never appeared in a request. It would not have mattered much if it had, because the address never contains anything from your file.

The part we had wrong

That ad request should not have been there. This site has no ads yet, and our own notes said the script makes no request for an ad until there is a space on the page to put one in. The capture said otherwise: a request went out on every page load, before any visitor had been asked for consent, which breaks one of the rules this site is built to. Our privacy page had also said Google receives your IP address and page only once ads are live. It was receiving both already.

Google provides a switch for exactly this, which holds every ad request until a consent choice has been made. It went live the same day, the privacy page was rewritten to match, and we ran the capture again on the live site.

The two that remain are the ad script itself and a second file it loads. Fetching them is what shows Google your IP address and the page you are on, and the privacy page says so in those words. An article like this one loads the same two files and sends Google nothing else.

We ran the after capture once more on 23 September, the day this was published, with a fresh browser and the same made-up file. The figures had not moved: two requests to Google, both for those files, no request for an ad, and the invented artist names reaching Deezer and nowhere else.

What changes when ads switch on

The plan for when this site starts showing ads is that a consent message comes first, and ad requests resume only after you have made a choice in it. From then on each request will carry parameters like the ones in the first table, and the ad network may set its own cookies. What it will not carry is your file. We will run the same capture again at that point, because a claim like this is only as good as its most recent check.

Check it yourself

You do not need our tools to test the part that matters, only the developer tools already in your browser.

1. Open the upload page on a computer and press F12, then choose the Network tab.
2. Read your export as normal and wait for your results.
3. Type one word from the name of an artist you listen to into the Network filter box. The only requests that match should go to api.deezer.com, for album art.
4. Turn album art off on the results page and clear the list. Open the Songs, Artists and Albums tabs and filter the same way. Nothing new should match. Art starts switched on each time the page loads, so a reload undoes this step.

The filter box matches request addresses rather than their contents, which is why our own capture also read the bodies. In this test there were none to read.