Random stock photos are fine for a screenshot, but they quietly break the moment you need a known size, an offline build, or a layout that looks the same on every reload. Here's when to reach for something more deliberate.
Every front-end developer has pasted a lorem-picsum URL into an <img> tag to fill a hole in a layout. It's fast, it's free, and it gives you a real photo instead of a grey box. For a one-off screenshot, that's exactly right. The trouble starts when the placeholder stops being a throwaway and becomes part of how you build — because a random remote photo has a handful of properties that quietly work against you the moment you're doing anything more serious than a demo.
The problem with a random photo
A service like lorem-picsum returns a different image on most requests, chosen from a large pool. That randomness is the whole appeal, and it's also the catch. If you're testing a card grid, every reload reshuffles the pictures — so you can never tell whether a layout shift came from your CSS or from a portrait photo landing where a landscape one was a second ago. When the content under test is meant to be identical between two runs, a non-deterministic placeholder adds noise to exactly the thing you're trying to measure.
The photos also vary wildly in their own dimensions and aspect ratios before your CSS gets hold of them. That's useful if you specifically want to stress-test how your layout handles unpredictable media. It's a liability when you're trying to check one thing at a time, because you can't hold the image constant while you vary the code.
Every placeholder is a network request
The part that's easy to forget: a remote placeholder is a live external dependency baked into your page. Each one is an HTTP request to a third-party server, which means your prototype now:
- doesn't render in a Docker build, on a plane, or on any machine without internet;
- leaks a request to an outside domain on every page load, which matters if the mockup is behind a client NDA or you're screen-sharing a design review;
- breaks silently the day the free service rate-limits you, changes its URL scheme, or goes down — and takes your demo with it.
None of that is hypothetical. Free placeholder services come and go, and a layout that depends on one is a layout with an expiry date you don't control. For a quick throwaway that's an acceptable trade. For a component library, a design system, or anything committed to a repo, it's a dependency you didn't need to take on.
What you usually actually want
Most of the time, the honest requirement isn't "a photo" — it's "a box of exactly these pixels, that I can see at a glance, that never changes." A grey rectangle that says 800 × 400 in the middle tells you more during layout work than a beautiful random landscape does, because you can read the dimensions straight off the page and confirm the slot is the size you meant it to be. It's deterministic, it's self-documenting, and it costs nothing to render.
The clean way to get that is an inline SVG placeholder — a tiny bit of vector markup, sized exactly as you specify, with a label baked in. Because it's just text, you can drop it straight into your HTML, or encode it as a data: URI and use it anywhere a URL is expected. That URI scheme is a stable web standard, not a trick:
"A 'data' URL [...] allows inclusion of small data items as 'immediate' data, as if it had been included externally. [...] data:[<mediatype>][;base64],<data>"
— RFC 2397, "The 'data' URL scheme"
Encode a small SVG that way and the image travels inside your document. No request, no external host, no reshuffle on reload — it renders identically offline, in CI, and in front of a client, forever. Our placeholder image generator builds exactly this: you set width, height, label text, and colours, and it hands back inline SVG as raw markup, a data URI, or a download — all in the browser, with nothing sent to a server.
When a random photo is the right call
None of this means picsum-style services are bad — they're just a different tool. Reach for a real random photo when the content is the point: a portfolio mockup you want to feel finished, a client presentation where grey boxes read as unfinished, or a deliberate test of how your layout copes with unpredictable image sizes and colours. In those cases the variety is the feature. The mistake is using a random remote photo as your default placeholder for everyday layout work, where determinism and zero dependencies matter far more than the picture being pretty.
A quick rule of thumb
Ask what the placeholder is standing in for. If it's standing in for a specific slot — this hero is 1200 × 600, this thumbnail is 150 × 150 — use a labelled inline placeholder so the size is visible and fixed. If it's standing in for real content you don't have yet and the vibe matters, a random photo is fine, as long as you remember it's a live network dependency. And once you swap in real images, keep them honest: run them through an image resizer so they match the box you designed for, and if you're shipping vector placeholders or icons, a quick pass through an SVG optimizer strips the markup down before it lands in your bundle.
Placeholders are scaffolding, and good scaffolding is boring, predictable, and doesn't phone home. Random photos are a fine way to fake being finished; deterministic labelled boxes are a better way to actually build. Pick the one that matches the job in front of you — and make the deterministic one your default.
← All articles