Cleaning 199 GB of duplicates out of Google Photos from inside Chrome

My Google account showed 1.7 TB of 2 TB used, and Google guessed about nine months until full. The next plan up is 10 TB for PLN 234.99 a month. One night later the bar said 1.5 TB. Claude scanned about 105,000 photos in Chrome and moved about 9,600 to the bin. That freed roughly 199 GB, with no Takeout and no downloads.

Google's own cleanup lists were not enough

The storage page has ready groups: screenshots, blurry photos, other apps. On my account they were wrong in the ways that matter. "Screenshots" held camera videos of Vimo Swim devices and family photos. "Blurry" mixed pocket shots with portraits that only had a soft background. We binned 33 obvious junk frames, 58.6 MB. Then I looked at the real number: large photos and videos, 536 GB.

Search did not help either. It is semantic, so "RAW" returned photos of raw meat.

The page already has everything

Google Photos has no API for deleting photos (check that against the current docs, it is from memory). But the web grid gives you plenty. Every tile has a link with the photo ID, an aria-label with the date and time to the second (it starts with "Raw photo" for RAW files), and a thumbnail of about 10 KB. Claude fetched each thumbnail inside the page, drew it onto a 9×8 canvas and made a 64-bit dHash. Nothing left the browser.

One RAW file was a Nikon D610 .NEF of 30.3 MB, next to a JPEG of a few MB. So the rule was simple: a RAW with a JPEG twin taken in the same second goes to the bin, and so does an identical copy with the same timestamp. Anything only "similar" waits for me.

The pilot month, January 2015, had 824 photos and 300 RAW files. 244 had a twin. With the copies, 271 items went to the bin and Google's own dialog said 7.4 GB.

What broke on the way

Most of the work was the run itself, not the idea.

• Search got throttled. After a few dozen month queries, every search returned "No results", even ones that worked an hour before. The fix was to stop searching and walk the main timeline from the oldest photo upwards, in chunks of about 1,500.
• Scroll positions drift. Photos re-measures rows while you scroll, so "go back to where the chunk started" landed in the wrong place. Selection now finds items by date instead of pixels.
• A black-and-white edit looked like a copy. dHash only sees brightness. Adding the average colour to the fingerprint fixed it, and the colourful copy is now the one that stays.
• Two jobs at once. A JavaScript call that times out keeps running in the page. I started the autopilot a second time by accident, and the two jobs ticked each other's checkboxes. Now it refuses to start twice.
• Trusted Types. Google blocks innerHTML, so the review overlay is built with plain DOM calls.

The result

69 chunks from 2002 to today. 191.7 GB from the full run, plus 7.4 GB from the pilot. Most of it was RAW from 2012 to 2016, often 10 to 19 GB per chunk. From 2017 the library was almost clean. Photos uploaded in "High quality" before June 2021 freed nothing at all, because they never counted against storage.

What stayed on purpose: RAW files without a twin, colour and B&W edits, 2,130 groups of similar shots for me to review, and 66 items on two very busy days that would not take a click. I suspect Google stacks RAW and JPEG into one tile there, and ticking it would take the JPEG too.

It took one evening to build and one night to run, with the Mac on caffeinate and the Photos window kept visible so Chrome would not slow the tab down. Next time I would start on the timeline from day one and skip search completely. I would also add the colour check before the first delete, not after. The script now lives as a Claude Code skill, so the next library is one command. The 536 GB of videos are a different story.