tteg vs SourceSplash — when to use which

Both tools exist to fill the gap Unsplash left when they retired source.unsplash.com/random in mid-2024. Both are free to start. They solve different problems, so this is a "when to use which", not a winner-take-all.

The short answer

→ Use SourceSplash if you want a drop-in URL replacement for source.unsplash.com/random — keep the <img src="..." /> pattern, change the host, done. Minimal refactor. Good for one-line fixes in existing templates.
→ Use tteg if an AI coding agent (Claude Code, Cursor, Codex) is building or editing your site and you want the photo committed into the repo, topic-matched to surrounding content, with a CLI, HTTP API, and MCP server the agent can call.

Side-by-side

Dimension	SourceSplash	tteg
Primary surface	URL host (HTTP GET returns an image)	CLI + HTTP API + MCP server + embeddable widget
Drop-in replacement for `source.unsplash.com/random`	yes (change the host)	indirect — `tteg save` writes a local file, then reference that
Topic-matched photos (query-driven)	yes	yes
Commits the photo into your repo at build time	no (runtime fetch only)	yes — `tteg save "query" ./public/hero`
Free-tier limit	1,000 req/day	50 req/day/IP on the public HTTP API; CLI is fully unlimited
Agent-native (MCP server for Claude Code / Cursor)	no	yes — native MCP tools for `search`, `save`, `batch`
Batch-fill an entire landing page from a manifest	one URL at a time	yes — `tteg batch manifest.json`
Pre-commit scanner (audit any URL for broken images)	no	tteg.kushalsm.com/scan
License	open source	MIT (github.com/kiluazen/tteg)
API key required	no	no

When SourceSplash is the better pick

You have an existing template with <img src="https://source.unsplash.com/random/..." /> and you want a one-line find-and-replace.
You're OK with a runtime external fetch for every page load.
You don't need topic-matched photos — random is fine.

When tteg is the better pick

An AI agent is generating your pages. tteg exposes a CLI, HTTP API, and MCP server, so the agent has a native affordance for "fetch a real photo now".
You want the photos committed into the repo so deploys don't depend on a runtime third-party fetch (faster load, no hotlink risk, no CORS headaches).
You want topic-matched photos — the image next to "coffee shop in Berlin" should actually be a coffee shop, not a random landscape.
You want a pre-commit audit step (the scanner) to verify no broken URLs slipped through.

Using both

These tools are not mutually exclusive. A reasonable stack:

→ Use tteg save or batch for primary hero / marketing assets (ships in the repo, fastest load, topic-matched).
→ Use SourceSplash for "just a random photo, I don't care what" blog placeholders, testing fixtures, or demo slots where runtime fetch is fine.
→ Use the tteg scanner to verify before every deploy that no placehold.co, picsum.photos, or dead source.unsplash.com/random URLs slipped through.

Both projects exist because Unsplash handled the deprecation badly — they shut down the endpoint without shipping a replacement and without a bulk-migration guide. Competing projects emerging in the gap is a good outcome for developers.

tteg on GitHub →

tteg vs SourceSplash — when to use which

The short answer

Side-by-side

When SourceSplash is the better pick

When tteg is the better pick

Using both

Related