By Rohit V.9 min readComparison
Placeholder Image Services Compared (2026)
TF
ToolsFuel Team
Web development tools & tips
Photo by Alvaro Reyes on Unsplash
Table of Contents
The Short Version
> Quick answer: For plain colored boxes with custom text, placehold.co is the best free placeholder image URL service in 2026 — it's actively maintained, fast, on a CDN, and outputs SVG, PNG, JPEG, GIF, WebP, and AVIF. For random real photos, Lorem Picsum (picsum.photos) is the go-to. dummyimage.com still works for basic colored placeholders. The one to stop using is via.placeholder.com — it was decommissioned after placeholder.com got acquired, and the service no longer serves images. If you'd rather not depend on any external service at all, generate placeholders locally with the ToolsFuel placeholder image generator, which builds them in your browser with no network call.
If you've hit a wall of broken images in an old project recently, you're not imagining it. via.placeholder.com — for years the default URL developers reached for — stopped working when its parent domain changed hands. I wrote about that whole saga in via.placeholder.com is dead. This post is the follow-up I kept meaning to write: a head-to-head of the placeholder services that are actually alive in 2026, so you can pick a replacement and move on.
I'll compare the live URL-based services on format support, customization, reliability, and licensing, then make the case for going fully local when you can. Picking the wrong one means another round of broken images in a year; picking right means you never think about it again.
If you've hit a wall of broken images in an old project recently, you're not imagining it. via.placeholder.com — for years the default URL developers reached for — stopped working when its parent domain changed hands. I wrote about that whole saga in via.placeholder.com is dead. This post is the follow-up I kept meaning to write: a head-to-head of the placeholder services that are actually alive in 2026, so you can pick a replacement and move on.
I'll compare the live URL-based services on format support, customization, reliability, and licensing, then make the case for going fully local when you can. Picking the wrong one means another round of broken images in a year; picking right means you never think about it again.
What Makes a Good Placeholder Service
Before the comparison, here's what I actually care about when picking one, learned the hard way from services that vanished:
Active maintenance. This is everything. The via.placeholder.com mess happened because the service was abandoned, then the domain got sold. A placeholder service is only as reliable as the team keeping it online. Check the GitHub activity or status page before you wire it into anything.
HTTPS and CDN delivery. Mixed-content warnings from an http-only placeholder are a non-starter on a modern site. The good services all serve over HTTPS from a CDN, so they're fast everywhere.
Format coverage. Some projects want SVG (smallest, scalable), some want PNG or JPEG, and modern pipelines increasingly want WebP or AVIF. The more formats a service supports, the fewer reasons you'll have to switch later.
URL-based customization. The whole point of these services is that you encode dimensions, colors, and text right in the URL — `https://placehold.co/600x400/orange/white?text=Hello`. No account, no API key, just a predictable URL pattern you can template in code.
Clear licensing. For colored-box placeholders this rarely matters, but for photo services (Lorem Picsum, Unsplash-based) you need to confirm the images are licensed for your use, especially if a placeholder accidentally ships to production. OpenReplay's roundup of image placeholder services is a decent external reference on the landscape. The traits that separate survivors from casualties are exactly these: active maintenance, HTTPS, CDN, and documentation.
Active maintenance. This is everything. The via.placeholder.com mess happened because the service was abandoned, then the domain got sold. A placeholder service is only as reliable as the team keeping it online. Check the GitHub activity or status page before you wire it into anything.
HTTPS and CDN delivery. Mixed-content warnings from an http-only placeholder are a non-starter on a modern site. The good services all serve over HTTPS from a CDN, so they're fast everywhere.
Format coverage. Some projects want SVG (smallest, scalable), some want PNG or JPEG, and modern pipelines increasingly want WebP or AVIF. The more formats a service supports, the fewer reasons you'll have to switch later.
URL-based customization. The whole point of these services is that you encode dimensions, colors, and text right in the URL — `https://placehold.co/600x400/orange/white?text=Hello`. No account, no API key, just a predictable URL pattern you can template in code.
Clear licensing. For colored-box placeholders this rarely matters, but for photo services (Lorem Picsum, Unsplash-based) you need to confirm the images are licensed for your use, especially if a placeholder accidentally ships to production. OpenReplay's roundup of image placeholder services is a decent external reference on the landscape. The traits that separate survivors from casualties are exactly these: active maintenance, HTTPS, CDN, and documentation.
The Live Services, Head to Head
Photo by Balázs Kétyi on Unsplash
Here's how the maintained services stack up in 2026.
placehold.co — best for colored boxes. This is my default recommendation. It's a simple, fast, free service that generates SVG, PNG, JPEG, GIF, WebP, and AVIF placeholders. The URL pattern is clean: `https://placehold.co/600x400` for a gray box, add `/FF5733/FFFFFF` for custom background and text colors, and `?text=Loading` for label text. It's actively maintained, CDN-backed, and the format range (including AVIF) is the widest of any free service. If you only learn one replacement, learn this one.
Lorem Picsum (picsum.photos) — best for real photos. When you want actual photography rather than a flat box, this serves random images from a curated set. `https://picsum.photos/600/400` gives you a random photo at those dimensions; add `?grayscale` or `?blur=2` for effects, or `/id/237/600/400` to lock a specific image. The photos are under the Unsplash license, so they're free for commercial and personal use — but double-check before any placeholder accidentally reaches production.
dummyimage.com — still works, basic. One of the older services, still online, still serving plain colored placeholders. `https://dummyimage.com/600x400/000/fff` for a black box with white text. It does the job but supports fewer formats than placehold.co and the project moves slowly. Fine as a fallback, not my first pick.
The ones to avoid. via.placeholder.com is decommissioned — don't use it. placeholder.com itself no longer serves images after the acquisition. Any tutorial or boilerplate still referencing those URLs is out of date; swap them out. I keep a find-and-replace handy to catch `via.placeholder.com` strings in old repos. Note also that one general caveat from recent 2026 coverage of these services is to always re-check a service's current terms before shipping, because the landscape shifts.
placehold.co — best for colored boxes. This is my default recommendation. It's a simple, fast, free service that generates SVG, PNG, JPEG, GIF, WebP, and AVIF placeholders. The URL pattern is clean: `https://placehold.co/600x400` for a gray box, add `/FF5733/FFFFFF` for custom background and text colors, and `?text=Loading` for label text. It's actively maintained, CDN-backed, and the format range (including AVIF) is the widest of any free service. If you only learn one replacement, learn this one.
Lorem Picsum (picsum.photos) — best for real photos. When you want actual photography rather than a flat box, this serves random images from a curated set. `https://picsum.photos/600/400` gives you a random photo at those dimensions; add `?grayscale` or `?blur=2` for effects, or `/id/237/600/400` to lock a specific image. The photos are under the Unsplash license, so they're free for commercial and personal use — but double-check before any placeholder accidentally reaches production.
dummyimage.com — still works, basic. One of the older services, still online, still serving plain colored placeholders. `https://dummyimage.com/600x400/000/fff` for a black box with white text. It does the job but supports fewer formats than placehold.co and the project moves slowly. Fine as a fallback, not my first pick.
The ones to avoid. via.placeholder.com is decommissioned — don't use it. placeholder.com itself no longer serves images after the acquisition. Any tutorial or boilerplate still referencing those URLs is out of date; swap them out. I keep a find-and-replace handy to catch `via.placeholder.com` strings in old repos. Note also that one general caveat from recent 2026 coverage of these services is to always re-check a service's current terms before shipping, because the landscape shifts.
The Case for Going Local
Every external placeholder service shares one flaw: it's a dependency you don't control. via.placeholder.com is the cautionary tale, but it could happen to any of them. A service gets acquired, runs out of funding, rate-limits you, or just goes down on the day of your demo. Your placeholders break, and if any leaked into a staging or production build, so does that.
Generating placeholders locally sidesteps all of it. A browser-based generator uses the Canvas API to draw the box, text, and colors entirely on your machine — no network request, no third-party uptime to worry about, nothing that can be decommissioned out from under you. The ToolsFuel placeholder image generator does exactly this: set width, height, background color, text color, and a label, then download the PNG or grab a data URI. Because it runs in your browser, it works offline and can't break when someone else's domain changes hands.
For design and prototyping work, local generation is almost always the better call:
- Wireframes and mockups — you want exact dimensions and consistent styling, which a local tool gives you precisely. - Offline development — on a plane or a flaky connection, external services fail; a local generator doesn't. - Sensitive projects — nothing leaves your device, so there's no question of a placeholder URL leaking internal context. - CI and automated tests — depending on an external service in a test suite is asking for flaky builds; generate fixtures locally instead.
When the placeholder needs to be an actual hosted URL — say, in a shared design doc or a CodePen — the URL services win on convenience. But for anything you build and run yourself, generating locally removes a whole category of future breakage. If you're inlining those generated images, the data URI vs external images guide covers when that's worth doing.
Generating placeholders locally sidesteps all of it. A browser-based generator uses the Canvas API to draw the box, text, and colors entirely on your machine — no network request, no third-party uptime to worry about, nothing that can be decommissioned out from under you. The ToolsFuel placeholder image generator does exactly this: set width, height, background color, text color, and a label, then download the PNG or grab a data URI. Because it runs in your browser, it works offline and can't break when someone else's domain changes hands.
For design and prototyping work, local generation is almost always the better call:
- Wireframes and mockups — you want exact dimensions and consistent styling, which a local tool gives you precisely. - Offline development — on a plane or a flaky connection, external services fail; a local generator doesn't. - Sensitive projects — nothing leaves your device, so there's no question of a placeholder URL leaking internal context. - CI and automated tests — depending on an external service in a test suite is asking for flaky builds; generate fixtures locally instead.
When the placeholder needs to be an actual hosted URL — say, in a shared design doc or a CodePen — the URL services win on convenience. But for anything you build and run yourself, generating locally removes a whole category of future breakage. If you're inlining those generated images, the data URI vs external images guide covers when that's worth doing.
A Quick Migration Checklist
Photo by Kelly Sikkema on Unsplash
If you're cleaning up a codebase that still references dead placeholder URLs, here's the order I work in:
1. Find every reference. Grep your project for `via.placeholder.com`, `placeholder.com`, and `placehold.it` (an even older dead one). Don't forget config files, seed data, Storybook stories, and test fixtures — placeholders hide everywhere.
2. Decide box vs photo per usage. Colored boxes with text → placehold.co. Realistic photos → Lorem Picsum. Most UI placeholders are boxes, so placehold.co covers the majority.
3. Update the URL pattern. via.placeholder.com used `https://via.placeholder.com/600x400`. The placehold.co equivalent is `https://placehold.co/600x400` — nearly identical, which makes the swap mostly mechanical. Watch for color and text query syntax differences.
4. Consider replacing demo placeholders with local ones. For anything in tests or offline-critical paths, generate the image locally with the placeholder image generator and commit the asset, so there's zero runtime dependency.
5. Add a lint rule or grep check. Drop a CI step that fails the build if `via.placeholder.com` reappears. New dependencies sneak in through copy-pasted snippets, and a guard catches them before they ship.
6. Template the URL pattern, don't hardcode. If you're generating dozens of placeholder URLs, wrap the pattern in a small helper so a future migration is a one-line change instead of a project-wide grep. Something like `const placeholder = (w, h) => 'https://placehold.co/' + w + 'x' + h` centralizes the dependency. I learned this exactly because the via.placeholder.com breakage would have been a single function edit if the previous team had done it, instead of 60 scattered string replacements.
The whole migration is usually an hour or two for a typical project, and it's the kind of debt that quietly grows — every broken placeholder is a small ding on whoever opens the project next. Worth doing in one pass.
A word on URL syntax differences, since they're the part of the migration that actually trips people. via.placeholder.com put the text in the path with plus-signs for spaces; placehold.co uses a `?text=` query parameter. via.placeholder.com colors were hex without the hash in the path; placehold.co accepts both named colors and hex in path segments. So a near-identical-looking URL can still render differently — always eyeball a couple of the migrated images rather than trusting that the swap was purely mechanical. I batch-test mine by opening five or six of the new URLs in browser tabs before committing.
One more thing I do on every cleanup: I add a short note in the project README listing which placeholder service the project uses and why, plus the local-generation fallback. It takes two minutes and means the next person who needs a placeholder reaches for the blessed approach instead of pasting a random URL from a five-year-old Stack Overflow answer. That single paragraph of documentation is what actually prevents the dead-URL problem from recurring.
For the broader set of free utilities I reach for during this kind of cleanup, the full ToolsFuel tools directory has the converters, formatters, and generators I lean on most — the color picker in particular pairs well with placeholder work when you're matching box colors to your design system.
1. Find every reference. Grep your project for `via.placeholder.com`, `placeholder.com`, and `placehold.it` (an even older dead one). Don't forget config files, seed data, Storybook stories, and test fixtures — placeholders hide everywhere.
2. Decide box vs photo per usage. Colored boxes with text → placehold.co. Realistic photos → Lorem Picsum. Most UI placeholders are boxes, so placehold.co covers the majority.
3. Update the URL pattern. via.placeholder.com used `https://via.placeholder.com/600x400`. The placehold.co equivalent is `https://placehold.co/600x400` — nearly identical, which makes the swap mostly mechanical. Watch for color and text query syntax differences.
4. Consider replacing demo placeholders with local ones. For anything in tests or offline-critical paths, generate the image locally with the placeholder image generator and commit the asset, so there's zero runtime dependency.
5. Add a lint rule or grep check. Drop a CI step that fails the build if `via.placeholder.com` reappears. New dependencies sneak in through copy-pasted snippets, and a guard catches them before they ship.
6. Template the URL pattern, don't hardcode. If you're generating dozens of placeholder URLs, wrap the pattern in a small helper so a future migration is a one-line change instead of a project-wide grep. Something like `const placeholder = (w, h) => 'https://placehold.co/' + w + 'x' + h` centralizes the dependency. I learned this exactly because the via.placeholder.com breakage would have been a single function edit if the previous team had done it, instead of 60 scattered string replacements.
The whole migration is usually an hour or two for a typical project, and it's the kind of debt that quietly grows — every broken placeholder is a small ding on whoever opens the project next. Worth doing in one pass.
A word on URL syntax differences, since they're the part of the migration that actually trips people. via.placeholder.com put the text in the path with plus-signs for spaces; placehold.co uses a `?text=` query parameter. via.placeholder.com colors were hex without the hash in the path; placehold.co accepts both named colors and hex in path segments. So a near-identical-looking URL can still render differently — always eyeball a couple of the migrated images rather than trusting that the swap was purely mechanical. I batch-test mine by opening five or six of the new URLs in browser tabs before committing.
One more thing I do on every cleanup: I add a short note in the project README listing which placeholder service the project uses and why, plus the local-generation fallback. It takes two minutes and means the next person who needs a placeholder reaches for the blessed approach instead of pasting a random URL from a five-year-old Stack Overflow answer. That single paragraph of documentation is what actually prevents the dead-URL problem from recurring.
For the broader set of free utilities I reach for during this kind of cleanup, the full ToolsFuel tools directory has the converters, formatters, and generators I lean on most — the color picker in particular pairs well with placeholder work when you're matching box colors to your design system.
Frequently Asked Questions
What's the best placeholder image service in 2026?
For colored boxes with custom text, placehold.co is the best free option — actively maintained, CDN-delivered, and it outputs SVG, PNG, JPEG, GIF, WebP, and AVIF. For random real photos, Lorem Picsum (picsum.photos) is the standard. If you'd rather not depend on any external service, generate placeholders locally with the [ToolsFuel placeholder image generator](/tools/lorem-pixel-generator).
What replaced via.placeholder.com?
via.placeholder.com was decommissioned after placeholder.com was acquired, and it no longer serves images. The closest drop-in replacement is placehold.co, which uses a nearly identical URL pattern (placehold.co/600x400). For the full story on why it broke, see [via.placeholder.com is dead](/blog/via-placeholder-com-dead-best-2026-replacements). Local generation is an even more reliable option.
What's the difference between placehold.co and Lorem Picsum?
placehold.co generates flat colored boxes with optional custom text, dimensions, and colors — ideal for UI placeholders and wireframes. Lorem Picsum (picsum.photos) serves random real photographs at your requested dimensions, better when you need realistic imagery rather than a labeled box. Use placehold.co for layout work and Picsum for photo-style placeholders.
Are placeholder image services safe to use in production?
Generally no — they're meant for development and prototyping. External services can go down, get acquired, or rate-limit you, which is exactly what happened to via.placeholder.com. If a placeholder accidentally ships to production it can break visibly. For anything reaching production, generate and host your own images, or use a local generator and commit the asset.
How do I generate placeholder images without an external service?
Use a browser-based generator that draws the image locally with the Canvas API. The [ToolsFuel placeholder image generator](/tools/lorem-pixel-generator) lets you set width, height, background color, text color, and a label, then download a PNG or copy a data URI — all without a network request, so it works offline and can't be decommissioned. Browse the rest of the [free tools](/tools) for related utilities.
Does Lorem Picsum let me pick a specific image?
Yes. Use the /id/ path segment: picsum.photos/id/237/600/400 always returns the same image (id 237) at 600x400. You can also add ?grayscale for a black-and-white version or ?blur=2 for a blur effect. The full list of available image IDs is on the Lorem Picsum site. The photos are under the Unsplash license, free for commercial and personal use.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools