Placeholder Images in 2026 — When to Inline SVG and When to Just Download a PNG

The first time placeholder.com went down, I noticed it because my staging environment for an e-commerce site suddenly had zero product images. We had been using placeholder URLs for products that were not yet photographed, and a few of those URLs had ended up in production data through a path nobody had documented. When the third-party service had an outage, our customers saw broken image icons.

That incident pushed me to never depend on a third-party placeholder service again. The same logic that makes you not trust random CDNs for production images applies to placeholders. The convenience is real but the dependency is silly.

Building your own placeholders is also not hard. The Placeholder Image Generator on ToolBox Hub generates them in the browser — no network call, no leak, no dependency. This article is about why that matters, when to use SVG vs PNG, and the surprising number of edge cases in CMS systems and email clients where placeholder choices break in non-obvious ways.

A Brief History of "via.placeholder.com" Era

In the early 2010s, placeholder image services were everywhere in tutorials, design tools, and prototype code. The format was simple: a URL like https://via.placeholder.com/400x300 would return a 400-by-300 PNG of a gray rectangle with the dimensions written across it. You could specify colors, custom text, and various format extensions. The whole thing was free.

It worked because the bandwidth cost was low (these are tiny images), the URL pattern was memorable, and the service was reliable enough. Designers loved it because they could prototype layouts without sourcing real images. Developers loved it because they could test their image-handling code without needing to set up real image hosts.

The problem with the service-based approach became visible over time. Services went offline. Domains lapsed. CORS policies changed. Some services started showing ads in placeholders. Some started rate-limiting. The fundamental issue was that you were depending on someone else's infrastructure to render gray boxes.

The shift to local generation is one of those small quality-of-life improvements that adds up. Tools like the Placeholder Image Generator draw the placeholder in your browser using a canvas element or SVG markup, and let you download or copy the result. You get the same convenience without the network dependency.

SVG vs PNG vs JPEG — Pick the Right Format

Most placeholder use cases fall into one of three buckets, and each has a clear best format.

Use SVG when: You need a placeholder that scales — responsive layouts, retina displays, mockups that get exported at multiple sizes. Inline SVG is also the only format you can embed directly in HTML without a separate file. The file size of a 400x300 SVG placeholder is roughly 200 bytes; the equivalent PNG is around 1500 bytes; the equivalent JPEG is roughly 4000 bytes (because JPEG compression is bad at large flat areas of single colors).

Use PNG when: You specifically need a raster image. Examples include testing the image upload pipeline, generating placeholders for code that does not handle SVG, or when you need a placeholder with transparency. PNG also wins when the placeholder needs to be loaded by a <img> tag and the surrounding stack does not handle inline SVG well.

Use JPEG when: Almost never, but valid cases include testing JPEG-specific code paths, generating placeholders for content management systems that strip SVG and reject PNG transparency, or when storage cost is a concern at extreme scale (which it almost never is for placeholders).

I default to SVG for design-time work and PNG for any production-adjacent code that touches an image pipeline. JPEG never enters my placeholder workflow.

Inline SVG vs External SVG vs Data URI

Once you have settled on SVG, there are three different ways to use it.

Inline SVG in HTML:

<svg width="400" height="300" xmlns="http://www.w3.org/2000/svg">
  <rect width="100%" height="100%" fill="#cccccc"/>
  <text x="50%" y="50%" text-anchor="middle" fill="#666">400 × 300</text>
</svg>

This is the most flexible — you can style it with CSS, animate it, and the markup is right there. The downside is that it bloats your HTML and is harder to cache than a separate file.

External SVG file referenced as <img src="placeholder.svg">:

<img src="/images/placeholder.svg" alt="Product placeholder">

This is what you want for repeated use of the same placeholder. The browser caches it, and the HTML stays clean. The downside is the extra HTTP request.

Data URI in CSS or HTML:

.placeholder {
  background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='400' height='300'><rect width='100%25' height='100%25' fill='%23ccc'/></svg>");
}

This embeds the entire SVG in the URL. No separate file, no HTTP request, no parser issues. The downside is that the URL gets long, has to be URL-encoded (note the %25 for % and %23 for #), and is annoying to read or modify.

For one-off placeholders in a single component, inline SVG is fine. For repeated placeholders across a site, an external SVG file is usually right. For CSS background placeholders, data URIs are the cleanest because they keep the placeholder definition in the same place as the styles that use it.

Generating Placeholders Without a Network

The Placeholder Image Generator workflow looks like this:

1. Set the dimensions (width, height)
2. Choose colors (background, text)
3. Set the text (defaults to the dimensions)
4. Choose the format (SVG, PNG, or JPEG)
5. Download the file or copy as data URI

For PNG generation, the tool uses an HTML5 canvas, draws the placeholder, and exports as a base64 image. For SVG, it constructs the markup directly. The whole thing happens in the browser — no images are uploaded anywhere, no third-party requests.

If you are dealing with a project that produces placeholders in bulk (e.g., generating images for hundreds of category cards in a design system), this approach is much faster than visiting a service URL repeatedly. The SVG output also scales without quality loss, which means a single placeholder file can serve all the breakpoints in your responsive layout.

For batch generation, I usually open the tool, configure the standard placeholder for my project (color scheme, font), and then change just the dimensions for each variation. The download is one click and the file goes wherever I drag it.

Sizing Placeholders for Open Graph and Social Cards

A specific use case that comes up: you need an Open Graph image for a blog post or a social card for sharing. The recommended dimensions vary by platform — Twitter wants 1200x675, Facebook wants 1200x630, LinkedIn is comfortable with either. A common approach is to standardize on 1200x630 and accept some cropping on Twitter.

The OG Image Generator on ToolBox Hub is designed for this specific case — it includes the right dimensions, a layout with title and subtitle, and brand color presets. For draft content where you have not yet decided the final image, generating a placeholder with the right dimensions and the post title overlaid is fast and means the link previews will at least be correctly proportioned.

If you are testing an image-loading flow with placeholder images, the Image Resizer lets you generate variations of a placeholder at different sizes — useful for srcset testing or for generating thumbnail and full-size versions of the same placeholder.

A CSS Pattern for "Image Loading" Placeholders

A common need is to show a placeholder while a real image loads, then fade in the real image when it is ready. Here is a pattern that works without any JavaScript:

.image-container {
  position: relative;
  background: #e0e0e0;
  background-image: url("data:image/svg+xml;utf8,...");
  background-size: cover;
  background-position: center;
}

.image-container img {
  width: 100%;
  height: auto;
  opacity: 0;
  transition: opacity 300ms ease-in;
}

.image-container img.loaded {
  opacity: 1;
}

The container has a placeholder background that is visible until the real image loads. JavaScript adds the .loaded class when the image's load event fires, fading the real image over the placeholder. The transition uses a smooth ease-in (see the CSS Cubic Bezier Generator for picking the right curve).

The placeholder data URI in the background can be a generic gray box (cheap), a blurred low-quality image preview (better, but requires generating one per image), or a colored block matching the dominant color of the eventual image (best, but requires extracting the dominant color).

Accessibility and Placeholders

Decorative placeholders should not be announced by screen readers. The proper handling depends on how the placeholder is used.

For <img> tags with placeholders: Use alt="" (empty string, not missing) when the image is purely decorative. When the image will eventually be replaced with content, the placeholder's alt should describe the intended content, not the placeholder itself.

For inline SVG placeholders: Add aria-hidden="true" if the SVG is decorative. If the SVG conveys information, give it a <title> element that describes its purpose.

For background-image placeholders: These are invisible to screen readers regardless. Backgrounds via CSS background-image are presentational, not content. The accessibility concern is the visual layout — does the placeholder make the page look broken to a sighted user using high-contrast mode? Test with the browser's contrast inversion settings and see.

A common mistake I see is alt text like "placeholder image" or "image not loaded yet." Both of these are wrong. The user who hears that does not gain any information about what the page is about. Either describe what the eventual content will be, or mark the image as decorative entirely.

CMS Pitfalls

A few cases where placeholder choices break in non-obvious ways:

WordPress strips inline SVG. WordPress has historically removed inline SVG from post content as a security measure, treating SVG as an attack vector. The fix is either to install a plugin that whitelists SVG (with the security tradeoffs that implies), upload the SVG as a file via Media and reference it by URL, or use PNG instead.

Email clients hate SVG entirely. No major email client renders SVG. If your placeholder is going in an HTML email, use PNG or JPEG. Period. This catches people who design newsletter templates and forget that the email rendering environment is a decade behind the web.

Some markdown renderers escape SVG. Hugo, Jekyll, and other static site generators usually pass SVG through correctly, but some markdown processors (especially in the Rails ecosystem) sanitize HTML aggressively and remove SVG markup. Test before relying on inline SVG in user-generated markdown.

iOS Safari has historically had quirks with data URIs. Older iOS versions had issues with very long data URIs in CSS background-image. This is mostly resolved in current Safari, but if you are supporting older devices, keep your placeholder data URIs short.

Print stylesheets do not always include placeholders. When a user prints a page, default browser styles often hide background-images. If the placeholder is purely a CSS background, it disappears in print. For pages that need to print well, use <img> placeholders rather than CSS backgrounds.

What I Actually Do

For my own projects, the placeholder workflow is roughly:

1. Mocking up a layout: Inline SVG, generated quickly via the Placeholder Image Generator. Gray background, dimensions overlaid.

2. Testing image-loading code: PNG files in a /placeholders/ directory. Same dimensions as the real images will be, named matching the real assets.

3. Open Graph and social cards: SVG to PNG. The OG Image Generator generates the SVG, then I export as PNG because every platform that consumes OG images requires raster format.

4. Production placeholder pattern: CSS background-color matching the eventual image's dominant color, plus a tiny LQIP data URI. The real image fades in on top via the JS pattern above.

5. Email templates: Always PNG. Hosted on a real CDN, never on a third-party placeholder service.

The mental model that works for me: placeholder generation is about getting visual feedback in design and dev workflows. Production rendering is about delivering real content. Mixing them up — using third-party placeholders in production, or production CDN-hosted images in throwaway prototypes — leads to the kinds of weird outages and unnecessary costs that come up when nobody is paying attention.

The Punchline

Placeholders are infrastructure, not content. Treat them like infrastructure: keep them under your control, generate them locally, and pick the format that matches your downstream need. SVG is the right default for most things, PNG when you need raster, JPEG almost never. The Placeholder Image Generator is the tool I reach for to do all of this without a network round trip — and that is the point.

If you are still using a third-party placeholder service in production code, change it. The five minutes of work saves you the embarrassing day when their service goes down and your product images vanish.