9 min readArticle
via.placeholder.com Is Dead — What to Use Instead
TF
ToolsFuel Team
Web development tools & tips
Photo by Jilbert Ebrahimi on Unsplash
Table of Contents
The Morning Half My Mockups Went Blank
> **Quick answer:** via.placeholder.com is effectively dead — the host has been unstable and intermittently offline since late 2024 and there's no official replacement coming. Switch to **Lorem Picsum** (`picsum.photos`) for photo placeholders, **DummyJSON Images** or an **inline SVG** generator for sized rectangles, or self-host a tiny SVG endpoint. Don't trust any free third-party image host for production.
I opened a client dashboard last week and three product cards were broken. The little gray boxes with `300×200` written across them — gone. Console was full of `ERR_CONNECTION_RESET` errors pointing at `via.placeholder.com`. I'd been using that host for placeholders since 2018, and it had finally given up.
Turns out I wasn't the only one. The service has been intermittently down for months, and the once-reliable subdomain has been flapping between 404s, connection resets, and full DNS timeouts. There's no announcement, no migration path, no replacement domain — it's just slowly rotting.
I went down the rabbit hole that morning and rebuilt my whole placeholder strategy. Here's what's actually working in 2026, what I avoid now, and the one-line tricks I wish I'd known years ago. If you've still got `via.placeholder.com` URLs in your codebase, this is your nudge to grep them out.
I opened a client dashboard last week and three product cards were broken. The little gray boxes with `300×200` written across them — gone. Console was full of `ERR_CONNECTION_RESET` errors pointing at `via.placeholder.com`. I'd been using that host for placeholders since 2018, and it had finally given up.
Turns out I wasn't the only one. The service has been intermittently down for months, and the once-reliable subdomain has been flapping between 404s, connection resets, and full DNS timeouts. There's no announcement, no migration path, no replacement domain — it's just slowly rotting.
I went down the rabbit hole that morning and rebuilt my whole placeholder strategy. Here's what's actually working in 2026, what I avoid now, and the one-line tricks I wish I'd known years ago. If you've still got `via.placeholder.com` URLs in your codebase, this is your nudge to grep them out.
What Actually Happened to via.placeholder.com
Photo by Michael Dziedzic on Unsplash
Short version: nobody's officially said "it's dead," but the behavior tells the story. The domain still resolves, but responses are inconsistent. Some regions get a 200 back. Others get connection resets. A lot of CI runs that hit the URL during snapshot tests started failing randomly in late 2024, and by 2026 it's basically a coin flip whether the image loads.
I'm guessing the host got tired of serving billions of free requests with no funding. The service was always a side project — a tiny Node app spitting out canvas-rendered placeholders. The bandwidth bill on something that popular adds up fast. When the SSL cert expired briefly last year and nobody fixed it for a few days, that was the first sign the lights had gone out internally.
The lesson I took away: free third-party image hosts are great until they aren't, and when they break they take production with them. I'd rather depend on my own SVG endpoint or a host with a clear sponsor model than a hobby project that could vanish.
A quick note on the related domain `placeholder.com` — that one redirects to a marketing page now and was never the image host. People mix them up. The actual image service was always at the `via.` subdomain.
If you're wondering whether you can just self-host the original placeholder source, the answer is sort of. There's an archived GitHub repo with a thirty-line Node script that powered the original service. Cloning it and running it on your own infrastructure works fine for internal tools, but at that point you've signed up to be the hosting provider, which kind of defeats the purpose. The reason placeholder URLs existed was so you didn't have to think about hosting. If you're going to think about it, you might as well think about a better solution — which is where the SVG and Picsum options come in.
I'm guessing the host got tired of serving billions of free requests with no funding. The service was always a side project — a tiny Node app spitting out canvas-rendered placeholders. The bandwidth bill on something that popular adds up fast. When the SSL cert expired briefly last year and nobody fixed it for a few days, that was the first sign the lights had gone out internally.
The lesson I took away: free third-party image hosts are great until they aren't, and when they break they take production with them. I'd rather depend on my own SVG endpoint or a host with a clear sponsor model than a hobby project that could vanish.
A quick note on the related domain `placeholder.com` — that one redirects to a marketing page now and was never the image host. People mix them up. The actual image service was always at the `via.` subdomain.
If you're wondering whether you can just self-host the original placeholder source, the answer is sort of. There's an archived GitHub repo with a thirty-line Node script that powered the original service. Cloning it and running it on your own infrastructure works fine for internal tools, but at that point you've signed up to be the hosting provider, which kind of defeats the purpose. The reason placeholder URLs existed was so you didn't have to think about hosting. If you're going to think about it, you might as well think about a better solution — which is where the SVG and Picsum options come in.
My Replacement Stack — Three Options I Actually Use
I don't use a single tool anymore. I pick based on what the placeholder is for.
**Option 1: Lorem Picsum (`picsum.photos`)** — best for realistic photo placeholders in mockups, marketing previews, and design comps. The URL pattern is dead simple: `https://picsum.photos/800/600`. You get a random photo at that size. Add `?random=1` to force a fresh image and `?blur=2` to soften it. I use this anywhere a real photo would eventually live — product cards, blog previews, avatar grids.
**Option 2: Inline SVG data URIs** — best for unit tests, Storybook, and anywhere I want zero network requests. A 200-byte SVG with the dimensions written inside renders instantly and never breaks. I keep a one-line helper:
```js const placeholder = (w, h, label = `${w}x${h}`) => `data:image/svg+xml;utf8,` + encodeURIComponent( `<svg xmlns='http://www.w3.org/2000/svg' width='${w}' height='${h}'>` + `<rect width='100%' height='100%' fill='#e5e7eb'/>` + `<text x='50%' y='50%' text-anchor='middle' dy='.3em' font-family='sans-serif' fill='#6b7280'>${label}</text>` + `</svg>` ); ```
Paste it once, never touch a CDN again. If you want to validate the encoding output, drop it into the ToolsFuel URL encoder — you'll see exactly what bytes make it into the data URI.
**Option 3: A self-hosted SVG endpoint** — best for staging environments where you want consistent, sized placeholders without polluting the bundle. I run a 30-line Cloudflare Worker that returns an SVG when you hit `/placeholder/{w}/{h}`. Zero dependencies, no rate limits, fast everywhere. The Worker code is maybe ten lines longer than the snippet above with a `Content-Type: image/svg+xml` header and CORS. Total cost: free.
**Option 1: Lorem Picsum (`picsum.photos`)** — best for realistic photo placeholders in mockups, marketing previews, and design comps. The URL pattern is dead simple: `https://picsum.photos/800/600`. You get a random photo at that size. Add `?random=1` to force a fresh image and `?blur=2` to soften it. I use this anywhere a real photo would eventually live — product cards, blog previews, avatar grids.
**Option 2: Inline SVG data URIs** — best for unit tests, Storybook, and anywhere I want zero network requests. A 200-byte SVG with the dimensions written inside renders instantly and never breaks. I keep a one-line helper:
```js const placeholder = (w, h, label = `${w}x${h}`) => `data:image/svg+xml;utf8,` + encodeURIComponent( `<svg xmlns='http://www.w3.org/2000/svg' width='${w}' height='${h}'>` + `<rect width='100%' height='100%' fill='#e5e7eb'/>` + `<text x='50%' y='50%' text-anchor='middle' dy='.3em' font-family='sans-serif' fill='#6b7280'>${label}</text>` + `</svg>` ); ```
Paste it once, never touch a CDN again. If you want to validate the encoding output, drop it into the ToolsFuel URL encoder — you'll see exactly what bytes make it into the data URI.
**Option 3: A self-hosted SVG endpoint** — best for staging environments where you want consistent, sized placeholders without polluting the bundle. I run a 30-line Cloudflare Worker that returns an SVG when you hit `/placeholder/{w}/{h}`. Zero dependencies, no rate limits, fast everywhere. The Worker code is maybe ten lines longer than the snippet above with a `Content-Type: image/svg+xml` header and CORS. Total cost: free.
Why I Don't Recommend dummyimage.com or fakeimg.pl Anymore
Photo by Gaspar Uhas on Unsplash
These are the two services everyone suggests when `via.placeholder.com` breaks. I tried both before settling on the stack above, and they have the same fundamental problem — they're free third-party hosts. Which means they could go the same way.
`dummyimage.com` is currently fine. Fast, stable, decent uptime. The URL pattern is `https://dummyimage.com/600x400/000/fff`. I used it for about a month after the placeholder.com meltdown. Then I realized I was just rolling the same dice with a different vendor.
`fakeimg.pl` works but the response times are inconsistent — sometimes 80ms, sometimes 2 seconds. That makes it bad for snapshot tests and worse for any page where layout shift matters.
If you have to use a third-party host, dummyimage is the better pick today. But the inline SVG approach is faster, more reliable, and doesn't add any DNS lookups to your page load. Lighthouse will thank you. So will anyone running the site on flaky mobile data.
There's also `placekitten.com`, which serves random cat photos at any size. It's mostly a joke service that became weirdly reliable. I use it in demo apps when I want clients to smile during a kickoff.
And one I keep seeing recommended on Twitter that I'd avoid: random subreddit-scraping image services. They look fun in a tutorial but they pull copyrighted content with no licensing, and if a client ever asks where the image came from, you don't have a good answer. Stick with Picsum (Unsplash-licensed), your own SVG, or self-hosted assets.
`dummyimage.com` is currently fine. Fast, stable, decent uptime. The URL pattern is `https://dummyimage.com/600x400/000/fff`. I used it for about a month after the placeholder.com meltdown. Then I realized I was just rolling the same dice with a different vendor.
`fakeimg.pl` works but the response times are inconsistent — sometimes 80ms, sometimes 2 seconds. That makes it bad for snapshot tests and worse for any page where layout shift matters.
If you have to use a third-party host, dummyimage is the better pick today. But the inline SVG approach is faster, more reliable, and doesn't add any DNS lookups to your page load. Lighthouse will thank you. So will anyone running the site on flaky mobile data.
There's also `placekitten.com`, which serves random cat photos at any size. It's mostly a joke service that became weirdly reliable. I use it in demo apps when I want clients to smile during a kickoff.
And one I keep seeing recommended on Twitter that I'd avoid: random subreddit-scraping image services. They look fun in a tutorial but they pull copyrighted content with no licensing, and if a client ever asks where the image came from, you don't have a good answer. Stick with Picsum (Unsplash-licensed), your own SVG, or self-hosted assets.
How to Grep Out via.placeholder.com Without Breaking Things
When I found the broken URLs in my client's app, there were 47 of them across 12 files. I didn't want to swap them one at a time, so here's the workflow I used.
First, find every reference. From the project root:
``` grep -rn 'via\.placeholder\.com' src/ --include='*.{ts,tsx,js,jsx,html,md,mdx}' ```
Sort by file. For each file, look at the surrounding context — is this a mockup that should become a real image, or a placeholder that's staying? Mockups get replaced with real Unsplash or product photos. Placeholders get the inline-SVG helper.
Second, write a tiny codemod. If your URLs follow the `https://via.placeholder.com/{w}x{h}` pattern, you can swap them automatically:
```js // codemod.js — run with: node codemod.js import { readFileSync, writeFileSync } from 'node:fs'; import { globSync } from 'glob';
const files = globSync('src/**/*.{ts,tsx,js,jsx}'); const re = /https:\/\/via\.placeholder\.com\/(\d+)x(\d+)/g;
for (const f of files) { const before = readFileSync(f, 'utf8'); const after = before.replace(re, 'https://picsum.photos/$1/$2'); if (before !== after) writeFileSync(f, after); } ```
Run it, eyeball the diff, commit. The diff in my client's repo was clean — every URL got swapped to a Picsum equivalent at the same dimensions. The cards loaded again on first deploy.
If you're worried about layout shift, set explicit `width` and `height` attributes on the `<img>` tag. The browser reserves the space before the image arrives, so Picsum's variable response times don't jolt the page. If you're not sure what your current images measure, you can drop a screenshot into the color picker and grab the pixel grid manually — though most modern browsers show dimensions in the Elements panel when you hover.
First, find every reference. From the project root:
``` grep -rn 'via\.placeholder\.com' src/ --include='*.{ts,tsx,js,jsx,html,md,mdx}' ```
Sort by file. For each file, look at the surrounding context — is this a mockup that should become a real image, or a placeholder that's staying? Mockups get replaced with real Unsplash or product photos. Placeholders get the inline-SVG helper.
Second, write a tiny codemod. If your URLs follow the `https://via.placeholder.com/{w}x{h}` pattern, you can swap them automatically:
```js // codemod.js — run with: node codemod.js import { readFileSync, writeFileSync } from 'node:fs'; import { globSync } from 'glob';
const files = globSync('src/**/*.{ts,tsx,js,jsx}'); const re = /https:\/\/via\.placeholder\.com\/(\d+)x(\d+)/g;
for (const f of files) { const before = readFileSync(f, 'utf8'); const after = before.replace(re, 'https://picsum.photos/$1/$2'); if (before !== after) writeFileSync(f, after); } ```
Run it, eyeball the diff, commit. The diff in my client's repo was clean — every URL got swapped to a Picsum equivalent at the same dimensions. The cards loaded again on first deploy.
If you're worried about layout shift, set explicit `width` and `height` attributes on the `<img>` tag. The browser reserves the space before the image arrives, so Picsum's variable response times don't jolt the page. If you're not sure what your current images measure, you can drop a screenshot into the color picker and grab the pixel grid manually — though most modern browsers show dimensions in the Elements panel when you hover.
The Stack I Use Today (And Why I'd Bet on It)
For mockups and design comps: **Lorem Picsum**.
For unit tests, Storybook stories, and anything that runs in CI: **inline SVG data URIs** with the helper above.
For staging environments with consistent placeholders: a **self-hosted Cloudflare Worker** that returns sized SVGs.
For real production: **real images**, hosted somewhere I control, with explicit width and height attributes and a `loading="lazy"` attribute below the fold. No exceptions.
If you're rebuilding placeholder URLs anyway, this is a good time to audit the rest of your image pipeline. Are you serving WebP or AVIF? Do you have proper `srcset` attributes for retina screens? Are alt texts useful or just `"placeholder"`? The placeholder.com breakage cost me an afternoon, but I came out the other side with a better image story than I had going in.
I've also been using ToolsFuel's placeholder image generator when I need quick sized rectangles inside the browser without writing the SVG by hand — it spits out a PNG you can download or copy as a data URI. Same idea as the helper above, just clickable.
And if you want to dig into the broader picture of image-related dev tooling, my base64 encoding explainer covers when inline data URIs make sense and when they bloat your bundle. The MDN reference for data URLs is the canonical source if you want to go deeper into the syntax.
One last thought. The placeholder.com story is a microcosm of how the modern web works — we pile up dependencies on free services run by people we've never met, and we don't think about them until they break. Then we rebuild in two hours what we should have built right the first time. I've started keeping a one-page "third-party dependency audit" for each client project: every external service I rely on, the failure mode if it disappears, and the migration plan. It takes maybe an hour to fill out and it's saved me half a dozen fire drills since I started doing it. If you take one thing away from this post: do that audit on your own projects. You'll be surprised what you're depending on.
For unit tests, Storybook stories, and anything that runs in CI: **inline SVG data URIs** with the helper above.
For staging environments with consistent placeholders: a **self-hosted Cloudflare Worker** that returns sized SVGs.
For real production: **real images**, hosted somewhere I control, with explicit width and height attributes and a `loading="lazy"` attribute below the fold. No exceptions.
If you're rebuilding placeholder URLs anyway, this is a good time to audit the rest of your image pipeline. Are you serving WebP or AVIF? Do you have proper `srcset` attributes for retina screens? Are alt texts useful or just `"placeholder"`? The placeholder.com breakage cost me an afternoon, but I came out the other side with a better image story than I had going in.
I've also been using ToolsFuel's placeholder image generator when I need quick sized rectangles inside the browser without writing the SVG by hand — it spits out a PNG you can download or copy as a data URI. Same idea as the helper above, just clickable.
And if you want to dig into the broader picture of image-related dev tooling, my base64 encoding explainer covers when inline data URIs make sense and when they bloat your bundle. The MDN reference for data URLs is the canonical source if you want to go deeper into the syntax.
One last thought. The placeholder.com story is a microcosm of how the modern web works — we pile up dependencies on free services run by people we've never met, and we don't think about them until they break. Then we rebuild in two hours what we should have built right the first time. I've started keeping a one-page "third-party dependency audit" for each client project: every external service I rely on, the failure mode if it disappears, and the migration plan. It takes maybe an hour to fill out and it's saved me half a dozen fire drills since I started doing it. If you take one thing away from this post: do that audit on your own projects. You'll be surprised what you're depending on.
Frequently Asked Questions
Is via.placeholder.com officially shut down?
There's no official announcement, but the service has been effectively unreliable since late 2024. Responses are inconsistent — some regions get a 200, others get connection resets or DNS timeouts. The host appears abandoned. Treat it as gone and migrate any production URLs to a stable replacement like Lorem Picsum or an inline SVG. Don't rely on the domain coming back.
What's the best free replacement for via.placeholder.com?
For realistic photo placeholders, Lorem Picsum (`picsum.photos/{w}/{h}`) is the most stable option I've found. For sized rectangles in tests and Storybook, an inline SVG data URI is faster and never breaks. If you need a self-hosted option, a 30-line Cloudflare Worker can serve placeholder SVGs for free at any scale. I covered all three patterns in detail above.
Will Lorem Picsum also go down eventually?
Possibly. Any free third-party host can vanish. Lorem Picsum has been stable since 2017 and the maintainer has been clear about its hobby-project status, but the smart move is to use it for mockups and stage environments, not load-bearing production URLs. For anything critical, host your own images or use a paid CDN like Cloudflare Images or Bunny.net. Free is fine until it isn't.
How do I find every via.placeholder.com URL in my codebase?
Run a recursive grep from your project root: `grep -rn 'via\.placeholder\.com' src/ --include='*.{ts,tsx,js,jsx,html,md}'`. That'll list every file and line number. From there, write a quick codemod or just swap them by hand. If you want a sanity check on the new URLs, you can paste each one into the [ToolsFuel URL encoder](/tools/url-encoder-decoder) to see how it'll appear after encoding in href attributes or query strings.
Can I use an inline SVG as a placeholder image?
Yes, and it's the fastest option. An SVG with the dimensions baked in renders instantly, has zero network cost, and works offline. The trick is to URL-encode the SVG markup so it works as a data URI. The helper in the post above handles it in three lines of JavaScript. You can also pre-generate the data URIs at build time and inline them as constants — that's what I do for components that show placeholders 100+ times per page.
Should I host my own placeholder service?
For staging environments, yes. A Cloudflare Worker or tiny Express endpoint that returns sized SVGs takes 10 minutes to write and never breaks. For production, real images are almost always better — placeholders signal incomplete work and hurt trust. I only use placeholders during build, in tests, or in design comps that never ship to real users.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools