The Hunt for Free Images — Copyright, Broken URLs, and Hosting Headaches

 

I Need 78 Images

The screen design was complete. Stars drifting across the background, cards flipping with a satisfying 3D animation. The problem? There was nothing to show on the front of the flipped cards. A tarot deck has 22 Major Arcana and 56 Minor Arcana — 78 cards total. I needed images for all of them.

Using images from a commercial tarot deck would mean licensing fees. I was not keen on investing hundreds of dollars into a side project. That meant finding free images. And that is where an unexpectedly long journey began.

The Public Domain Trap: 1909 vs. 1971

The first thing that comes to mind for tarot images is the Rider-Waite-Smith (RWS) deck. Created in 1909 by Arthur Edward Waite with illustrations by Pamela Colman Smith, it is the standard of modern tarot. Most tarot apps use these images.

"1909 — the copyright must have expired, so I can use them freely," I thought. Half right, half wrong. Pamela Colman Smith's original black-and-white line drawings from 1909 are in the public domain in most countries. But the colorful version we commonly see tells a different story.

In 1971, US Games Systems published a recolored edition. The copyright on that coloring may still be in effect. In other words, the same illustration can have different copyright status depending on which version of the coloring you use. When I first asked the AI about this, the answer was "RWS is in the public domain, so you can use it freely." Not wrong per se, but critically missing the nuance about the color version.

Only after follow-up questions did I get the full picture about the 1971 recoloring's copyright status. An important lesson: do not take AI's first answer at face value, especially on legal matters. Always verify with follow-up questions.

First Attempt: Wikimedia

The safe play was to use images close to the 1909 originals. I confirmed that Wikimedia Commons hosted RWS tarot card images and gave it a try. All 78 cards were indeed uploaded, with reasonable file sizes and resolution.

The issue was reliability. Wikimedia's image URL structure is complex, and some filenames contain special characters. I initially implemented direct URL references. It worked fine for a few weeks. Then one day, some images simply stopped loading.

Whether Wikimedia changed the URL structure or experienced a temporary outage, I could not determine. But what I knew for certain was how dangerous it is to depend directly on an external service's URLs. If just 3 out of 78 images break, the app's credibility craters.

Internet Archive: Another Try, Another Instability

As an alternative to Wikimedia, I tried the Internet Archive. RWS tarot images were archived there too, with a seemingly more stable URL structure and decent image quality.

But the Internet Archive had its own problem: inconsistent loading speeds. Sometimes images loaded instantly; other times they took over 5 seconds. When the dramatic moment of flipping a tarot card is met with a 5-second loading delay, all the atmosphere is destroyed. I had spent time crafting a 0.8-second flip animation only to have a blank card stare back at me while an image loaded. Unacceptable.

I tried technical fixes like preloading and lazy loading, but you fundamentally cannot control an external server's response time. Preloading all 78 images makes the initial page load too heavy; loading on demand means empty cards at the moment of the flip.

The AI-Suggested URLs That Did Not Exist

The most confusing moment in this process deserves its own section. I asked the AI: "Give me stable sources hosting public-domain images of all 78 RWS tarot cards." The AI confidently provided several URLs — specific GitHub repository paths, API endpoints from specific websites.

I checked them one by one. More than half did not exist. A GitHub repository was real, but the image paths were wrong. A website API simply did not exist at all. The AI had generated plausible-looking URLs from whole cloth. This is a textbook case of AI hallucination.

This experience delivered the single most important lesson about AI collaboration. AI excels at code writing, design discussion, and idea brainstorming. But for concrete factual verification — "does this URL actually exist?" or "what is the latest version of this library?" — you must always check yourself. AI's "plausible information" and "accurate information" are entirely different things.

The Answer: Self-Hosting

After multiple false starts, the conclusion was simple. Host the images myself. Download all 78 public-domain-verified images from Wikimedia, and place them in the project's public folder.

The advantages are clear. No external dependencies means no broken URLs. Images deploy with the project, ensuring consistent loading speed. Optimized, the total size of 78 image files is perfectly manageable.

AI proved highly useful for the batch processing step. Writing a script to resize and convert images is where AI is accurate and fast. "Write a script that resizes 78 PNG images to 300px width and converts them to WebP" returned immediately usable code.

In Hindsight, Self-Hosting Was Always the Answer

From Wikimedia direct links to Internet Archive to asking AI for alternative sources — I took a roundabout path only to land on self-hosting. If I had reached this conclusion from the start, the task would have taken a single day.

But the detour was not entirely wasted. I gained a real understanding of the nuanced copyright status of public domain works. I felt firsthand the risk of depending on external resources. And I clearly identified the limits of AI when it comes to factual information. That last lesson significantly changed how I collaborate with AI for the rest of the project.

With AI, asking "how" yields excellent answers. But when asking "where" or "whether something exists," always verify yourself. This is the essential dividing line to remember in AI-assisted development.

Next Up

Images secured. Design complete. Now it is time to structure the actual code. In the next part, I will discuss the React component design process — how to effectively request component architecture from AI, the value of deliberately abandoning a perfect initial design, and why refactoring is a natural part of the process, not a failure.