If you maintain an open-source repo with a README full of screenshots, GIFs, or diagrams, there's a decent chance a chunk of your audience is staring at purple boxes where your content used to be. The images still exist. The URLs still resolve. Anyone in the UK who visits your project just can't see them.
This is the Imgur UK block. It's been live since September 30th, 2025, and seven months in, most people hitting "upload" on Imgur still have no idea.
What actually happened
The common assumption is this is a UK Online Safety Act story. Close, but not quite. The OSA is part of the backdrop, but the actual trigger was the ICO, the UK's data protection regulator. On 10th September 2025 they issued a notice of intent to fine MediaLab (Imgur's parent company) over its handling of children's data and age-assurance practices. Rather than comply, Imgur geo-blocked the UK a few weeks later.
The distinction matters. MediaLab's other services, Kik for example, are still available in the UK. They implemented age assurance and complied. Imgur chose not to. The ICO has also confirmed that leaving the UK doesn't make the fine go away.
So: commercial decision, not legal mandate. The result is the same either way. UK users get "Content not viewable in your region" where images used to be, and so far no other country has followed. UK-only for now, but the precedent is set.
Why nobody notices
The block isn't really the problem. The asymmetry is.
If you're a maintainer in the US, Germany, or Japan, your README looks exactly the same as it did last year. The images load fine. Nothing in your workflow tells you anything is wrong. You get the occasional issue filed, but broken README images don't stop anyone getting work done, so UK developers just quietly move on.
Popular tooling makes it worse. ShareX, one of the most-used screenshot tools on Windows, still ships with Imgur as its default anonymous upload destination. Millions of screenshots get uploaded with muscle-memory keystrokes, pasted into GitHub issues and READMEs, and are invisible to UK audiences from the moment they land. No feedback loop, no warning, nothing.
You get what you'd expect: a growing pile of broken content across open source, invisible to the people best placed to fix it.
The numbers
I run pkglnk, a transparent Git proxy for Unity packages that gives authors install analytics. One useful side effect is that we already index README content for every package we track, so I ran a count.
Across 2,612 Unity packages, 55 (2.1%) embed at least one Imgur-hosted image in their README. That's 210 individual images UK developers can't see when evaluating whether to use a package, out of 6,370 total README images across the dataset.
2.1% sounds small until you weigh it by impact. The 50 affected repos I could pull star counts for have over 14,000 combined GitHub stars. Five of them have more than 1,000 stars each. Eleven have more than 500. Over half are above 50. These aren't obscure hobby projects, they're toolbelt-staple Unity packages. marijnz/unity-toolbar-extender (1.9k stars), cakeslice/Outline-Effect (1.5k), DanielEverland/ScriptableObject-Architecture (1k), and asus4/tf-lite-unity-sample (~1k) are all affected. So is keijiro/KinoAqua.
It gets worse when you look at distribution inside the affected set. For most of those packages, Imgur isn't one image among many, it's the dominant host. Several have every single README image on Imgur, so their documentation is effectively blank to UK developers rather than partially broken. The worst single case has thirty Imgur-hosted images in one README.
The detection catches Imgur URLs inside markdown image syntax, HTML <img> tags, and bare links GitHub auto-renders. Textual mentions don't count.
Extrapolating, carefully
I could extrapolate this to a GitHub-wide number. I'm not going to. Unity devs aren't representative of GitHub as a whole, they skew indie and hobbyist, sitting in the Reddit-adjacent communities where Imgur took hold. Enterprise Java, ML research, and infrastructure code probably use Imgur at very different rates, and my data can't tell you which way.
What I'm comfortable saying is that small percentages of large ecosystems still add up. Even if the 2% rate holds across the wider Unity world of OpenUPM, the Asset Store, and GitHub's gamedev tag, we're looking at hundreds to low thousands of affected packages in Unity alone. Scale that reasoning to GitHub's full surface and the absolute count of broken READMEs across open source is easily in the tens of thousands, probably higher. The exact number is guesswork, the order of magnitude isn't.
If you maintain data on another ecosystem, npm, PyPI, crates.io, Packagist, I'd love to see you run the same query. The only honest way to know is to measure.
What to do about it
Stop uploading documentation images to Imgur. It was always an odd choice for technical content (trusting a consumer image service with your project's visual integrity) and now it's actively bad.
The replacement is free and already integrated. Drag-and-drop an image into any web editor for a README, issue, or PR, and GitHub uploads it to github.com/user-attachments/ and hands you a permalink. No third party, no geo-block risk, no account needed, no link rot when the host pivots. For anything that really belongs with the code, commit the image into a /docs folder in the repo itself.
For Unity packages specifically, use a Readme~ or Documentation~ folder. The trailing ~ tells Unity's asset importer to skip the folder entirely, so your images don't generate .meta files or show up in consumers' Project windows, but they're still committed to git and visible on GitHub. Same trick the official Unity packages use for their docs.
A .github/images/ folder works just as well and is more portable. Unity ignores dotfolders by default, most package tooling does the same, and .github is already the conventional home for repo-adjacent files like workflows and issue templates. If you ship packages across multiple ecosystems, that's probably your path of least resistance.
If you use ShareX, change the default uploader. Point it at S3, something self-hosted, or an alternative like imgbb or postimages if you want Imgur-shaped convenience with better longevity.
For years of old blog posts and READMEs full of dead Imgur links you can't face rewriting, there's a Chrome extension that proxies Imgur through DuckDuckGo's content proxy for UK users. Clever hack, but it's someone else's infrastructure. Fine as a stopgap, not a plan.
Link rot by policy
Imgur isn't broken. The images exist. The URLs resolve. The infrastructure works fine. A chunk of the internet just can't see them because of a regulatory dispute that has nothing to do with the content itself.
This is link rot by policy, not by technical failure. It's a relatively new failure mode, and Imgur won't be the last service to make the call. The economics of geoblocking against overlapping national compliance regimes favour the block over the compliance work, especially for services with thin margins and user-generated content.
If you're writing docs meant to last, treat third-party image hosts the way you already treat external JavaScript CDNs. Minimise exposure, prefer first-party hosting, assume anything you don't control will eventually break.
If you want to check your own project, open your README in an incognito window through a UK-based VPN. You might be surprised.
This analysis used pkglnk's Unity package dataset. If you maintain Unity packages and want install analytics without giving up your GitHub-hosted source of truth, pkglnk is at pkglnk.dev.
Top comments (0)