Follow-up to Google Drive Isn't a Drive Anymore - It's a Trap
In my last article, I called Google Drive a "content roach motel." Data checks in, data doesn't check out.
So I did what any reasonable person would do - I requested a full Google Takeout, deleted every photo from Google Photos, and downgraded my Google One subscription.
It took almost two days. And Google wasn't done screwing me yet.
The Export: Death by a Thousand Zips
Google Takeout doesn't give you a clean export. It gives you a pile of split zip archives with cryptic filenames:
takeout-20260406T202814Z-11-001.zip (50 GB)
takeout-20260406T202814Z-11-002.zip (32 GB)
takeout-20260406T202814Z-13-001.zip (749 MB)
takeout-20260406T202814Z-15-001.zip (1.7 GB)
takeout-20260406T202814Z-17-001.zip (11 GB)
takeout-20260406T202814Z-9-001.zip (1.9 GB)
That's just one account. My daughter's account was 7 archives totaling 167 GB. No manifest. No index. No merge tool. Every zip contains a Takeout/ root folder with service subfolders (Google Photos/, Drive/, Mail/, etc.), but which services are in which zip? You get to find out by opening each one.
There's no incremental export either. If you miss something or a zip is corrupted, you start the entire multi-hour export process over from scratch.
The Booby Traps
Here's where it gets fun. Google's servers run Linux. Your computer probably runs Windows or macOS. Google knows this. They don't care.
Trailing Spaces in Folder Names
Inside the Photos archive, I found folder names like this:
Google Photos/Todd, Miranda /metadata.json
See those trailing spaces? Perfectly valid on Linux. Completely illegal on Windows. The extraction just crashes:
FileNotFoundError: [Errno 2] No such file or directory:
'V:\...\Google Photos/Todd, Miranda /metadata.json'
After verifying all 118,096 extracted files, only 62 had naming issues - 6 from this Photos album (likely generated by Google's facial identification feature) and 56 Google Voice files with leading spaces where a caller ID was blank. That's 0.05%. Carelessness, not malice. But it still crashes your extraction if you don't handle it, and most people won't know why.
Metadata Separated from Photos
Every photo in the export has a companion .json sidecar file containing the metadata - dates, GPS coordinates, descriptions, camera info. None of this is embedded in the image's EXIF data where every photo application on earth expects it.
my-vacation-photo.jpg
my-vacation-photo.jpg.json
So your photos arrive without their metadata embedded. If you just dump them into any photo app, you lose all your dates, locations, and descriptions. You need custom code to merge the JSON back into the EXIF data.
To be fair, stripping EXIF on export could be a privacy feature - GPS coordinates, device info, and other sensitive data embedded in images is a real concern. But the JSON sidecars still contain all that data, so it's not actually protecting privacy. It's just moving the metadata to a non-standard format that most software won't read automatically. Google could give you the option to export with or without embedded EXIF. They don't.
No Bulk Delete
After exporting, I wanted to delete my photos from Google's servers. Reasonable, right? There is no "Delete All" button. There is no bulk delete API. There is no "Delete My Account Data" option that actually works.
I asked Google's own AI, Gemini, for help. It recommended two Google URLs that supposedly led to bulk deletion pages:
-
https://myaccount.google.com/delete-services-gateway- 404 -
https://myaccount.google.com/delete-services- 404
You can click those links yourself. They're still dead. When I told Gemini the links didn't work, it suggested Google may have removed those pages to make deletion more difficult.
Google's own AI couldn't find a working way to bulk-delete photos from Google's own service.
The Gemini Saga: 6 Scripts to Delete Your Own Data
Since there was no deletion page, I asked Gemini to write a browser automation script. What followed was a masterclass in how hostile Google's UI is - even to Google's own AI.
When I told Gemini the deletion URLs it gave me were dead, it offered this explanation:
"Google frequently updates the delete-services backend to remove the 'Photos' toggle specifically. They've started tying Photos directly into the 'Google One' storage pool, which often removes the 'Trash' icon from the Account Services menu."
Google's own AI theorizing that Google deliberately removed the easy deletion path.
Attempt 1: Used role="checkbox" selectors. Couldn't distinguish the header "Move to trash" button from the modal confirmation button. Clicked the same button twice and hung.
Attempt 2: I told Gemini it forgot the modal. It added dialog targeting but the reference check failed across DOM layers.
Attempt 3: Briefly worked, then stopped. Couldn't handle the lazy-loaded photo grid - deleted one batch, hit an empty viewport, quit. I had to manually scroll the page to "nudge" it into loading more content.
Attempt 4: Selecting 75 items at once crashed Google's Wiz framework with CUIERROR26. The UI threw scale(Infinity) in its CSS animations. Google's own frontend can't handle a user selecting too many of their own photos at once. At one point during this saga, Gemini also completely lost track of the conversation and started writing C# Playwright code instead of browser console JavaScript.
Attempt 5: Architecturally sound but wrong selectors:
[11:07:50 AM] Autonomous Engine Engaged.
[11:08:05 AM] Empty viewport. Scrolling for more data...
[11:08:08 AM] No more items found. Shutting down.
"Completed" in 18 seconds. 67.3 GB of photos remained.
Attempt 6: I gave up explaining and pasted the raw DOM HTML into the chat. Gemini immediately identified the real problem - Google's Wiz framework uses state-heavy accessibility attributes that ignore standard click events. With the actual DOM in hand, it finally produced a working script.
It took six attempts, me doing Gemini's debugging for it, and literally handing it Google's own source before I had a script that could delete my own photos. And even the working version needs babysitting - you restart it every time the browser's memory fills up from thousands of detached DOM nodes Google's framework leaves behind.
There are multiple Chrome extensions that do exactly this. The Google Photos Delete Tool has 9,000 users. The Delete All Google Photos extension has 10,000 users and describes itself as automating "bulk deletion of your Google Photos since Google doesn't allow you to." That second one charges money to remove a 500-per-day deletion cap - people are literally paying a third party for the ability to delete their own files. Its changelog tells the story: "v2.2 - Google changed a button slightly, breaking the extension. v2.3 - Fix another change that Google made." Google is actively breaking these tools. Across just two extensions, 19,000 people needed third-party software to delete their own photos. That's not a niche problem - that's a missing feature with a body count.
Oh, and once you've moved everything to trash? Gemini warned me that the "Empty Trash" button often fails on large libraries and I might need another automation script just to permanently delete what I already deleted.
Here's the final working script if you need it - paste it into your browser console on photos.google.com while viewing your library:
// See remove-all-automated.js in this repo
// Fair warning: it WILL break and you WILL need to restart it
The Real Cost
Let me add up what it takes to leave Google Photos:
- Request a Google Takeout - wait hours for the export to generate
- Download 100+ GB of split zip archives with cryptic filenames
- Write custom extraction code because the archives contain Windows-illegal paths (trailing spaces in folder names)
- Write custom metadata code (still needed) because EXIF data is stripped and stored in JSON sidecars
- Ask Google's own AI for help deleting - get two 404 links to deletion pages Google removed
- Argue with Gemini through 6 broken scripts before it produces one that works
- Run that script for almost 2 days because there's no bulk delete API
- Restart the script dozens of times because Google's UI framework leaks memory and detaches DOM nodes
- Possibly script the trash emptying too because the "Empty Trash" button chokes on large libraries
- Hope nothing is corrupted because there's no verification and no incremental re-export
This is not an accident. This is a strategy. Every one of these friction points exists because Google calculated that most people will give up somewhere between step 1 and step 7 and just keep paying for Google One.
What I Learned
The 175-byte placeholder files from my first article were the polite version of vendor lock-in. The Takeout export is the hostile version. Google will technically let you leave - they have to, regulators require it - but they'll make sure it hurts.
My data is now on my own drive, organized into real folders, with real files I can actually open. It took two days, two custom scripts, and more patience than any normal user would have.
That's the point. You're not supposed to make it through all ten steps. Most people won't. Google is counting on it.
Who This Really Hurts
I'm a software engineer with decades of experience. I have an AI team that writes custom tools. I can read DOM structures and debug browser automation scripts. And it still took me almost two full days to get my family's photos back.
If I need custom extraction scripts, a brute-force browser automation hack, and two days of babysitting to leave Google Photos - what chance does your mom have? Your grandparents? Your friend who just wants their kid's birthday photos on their own computer?
The answer is: none. They will never leave. They will keep paying for Google One. They will keep uploading to a service that holds their memories behind a paywall of inconvenience. Not because they chose Google - but because Google made sure they can't un-choose it.
The people who need to escape the most are the ones least equipped to do it. That's not a flaw in Google's system. That is the design.
The Downgrade Dark Pattern
Even after you've exported your data and deleted your photos, Google isn't done. When you try to downgrade your Google One plan, here's what they show you:
"You'll lose access to other benefits included in your current plan. If you use more than 200 GB, you can't: Send and receive emails on Gmail. Back up to Google Photos. Save to Google Drive. This will lower the storage limit for your family group, and they might run out."
Google knows exactly how much storage I'm using - 14.6 GB. Well under the 200 GB tier I'm downgrading to. They could say: "You're currently using 14.6 GB. You have plenty of room on this plan." Instead, they list everything you'll "lose" and imply your family will suffer. They don't tell you your actual usage. They tell you what bad things could happen.
This is textbook dark pattern design. Make the user afraid to click "confirm." Plant doubt. Protect the revenue stream. Even during the downgrade flow, Google is still trying to keep you paying.
A fair caveat: There may be easier ways to do this that we didn't find. But Google's own AI couldn't find them either. Gemini recommended deletion pages that 404'd, failed to write a working automation script five times in a row, and ultimately agreed that Google likely removed the easy paths on purpose. If a professional developer and Google's own AI can't find the easy way out - it's either hidden well enough to be effectively nonexistent, or it doesn't exist at all. The distinction doesn't matter much when you're the one trying to leave.
Tools
I've open-sourced the tools I built during this escape at github.com/LostBeard/free-your-data:
- ExtractTakeout.cs - C# script to extract Takeout zips into organized folders, handles Windows path issues, supports resume
- VerifyExtraction.cs - Verifies every extracted file against the source zips (existence, size match, reports renamed files)
- remove-all-automated.js - Browser console script to bulk-delete Google Photos (hardened edition with auto-refresh, stuck detection, and progress tracking)
If you're planning your own escape from Google, these might save you some time. Or at least some swearing.
Open source is pretty much the only way regular people can fight back against this kind of corporate lock-in. I can't change Google's business model. But I can make sure the next person who tries to leave has better tools than I did.
I Don't Hate Google
I want to be clear about that. Google has brilliant people building genuinely useful products. I still use Gemini for brainstorming - it's helped me solve real problems. Search is still the best in the world. Gmail works. Android is a good OS. I'm not writing this from a cave with a tinfoil hat.
But using Google services is Russian roulette. Some of them respect you. Some of them trap you. And you don't find out which one you're using until you try to leave. Google Photos looked like a generous, well-designed product for years - until the moment I wanted my photos back. Then every design decision revealed itself as a wall between me and my own data.
The problem isn't that Google is evil. The problem is that Google is a company that optimizes for retention, and "make it hard to leave" is a retention strategy. It doesn't matter whether any individual engineer intended to trap you. The system does. And the system is what you have to fight when you want out.
Google's original motto was "Don't be evil." They dropped it in 2018. That was the last honest thing they did.
Previously: Google Drive Isn't a Drive Anymore - It's a Trap
Top comments (0)