The rule is one sentence long: a placeholder image should be exactly the size of the image that will eventually replace it. Everything else — the common dimensions, the ratio math, the retina variants — flows from that. Pick the wrong size and you're testing the wrong layout; pick the right one and your design holds still when real photography lands. Here's what the right size is for every common job, and how to derive it when your slot isn't in anyone's table.
Because layout is geometry before it's art. A page renders around whatever space images claim, and if a placeholder claims 800×600 while the final photo is 1200×675, everything below it jumps the moment the real file arrives. That jump has a name and a metric: cumulative layout shift, CLS, one of Google's Core Web Vitals. Users feel it as buttons sliding out from under their thumbs. A placeholder at the exact final dimensions means zero shift, and it costs nothing but a moment of arithmetic up front.
Match the slot, then match the ratio. These are the dimensions most layouts actually use, with the 2× retina companion for each:
| Job | 1× size (CSS) | 2× asset | Ratio |
|---|---|---|---|
| Social link preview (og:image) | 1200 × 630 | 2400 × 1260 | 1.91 : 1 |
| Page hero banner | 1200 × 675 | 2400 × 1350 | 16 : 9 |
| Full-width background | 1920 × 1080 | 3840 × 2160 | 16 : 9 |
| Blog content image | 800 × 600 | 1600 × 1200 | 4 : 3 |
| Email header image | 600 × 300 | 1200 × 600 | 2 : 1 |
| Card thumbnail | 400 × 300 | 800 × 600 | 4 : 3 |
| Avatar / social square | 1080 × 1080 | 2160 × 2160 | 1 : 1 |
Two anchors worth memorizing: 600 pixels is the standard email content width, and 1200×630 is the safest og:image because every major social platform crops around it gracefully. YouTube thumbnails have their own spec, 1280×720 — if you're mocking those specifically, the YouTube thumbnail size reference has the full detail.
Divide width by height to get the ratio as a decimal — 16 ÷ 9 is 1.78 — then multiply whichever side you know. Width ÷ 1.78 gives height; height × 1.78 gives width. A hero that must be 400 pixels tall at 16:9 is 711 pixels wide, because 400 × 1.78 = 711.1, and you round to the nearest whole pixel. The same arithmetic at the common content width of 600 pixels:
| Aspect ratio | Decimal | Height at 600 px wide | Typical use |
|---|---|---|---|
| 16 : 9 | 1.78 | 338 px | Video, wide heroes |
| 3 : 2 | 1.5 | 400 px | Classic photography |
| 4 : 3 | 1.33 | 450 px | Content images |
| 1 : 1 | 1.0 | 600 px | Squares, avatars |
| 1.91 : 1 | 1.91 | 314 px | Social previews |
When the ratio is the unknown — a designer hands you a slot and you need its ratio — flip the division: 1200 ÷ 630 = 1.90, close enough to the 1.91 og:image standard that you can treat them as one.
Modern displays pack two physical pixels into every CSS pixel, so a slot that displays at 600×400 wants a 1200×800 file to look crisp. That's the entire 1×/2× system: same visual size, double the pixel density. In practice you generate the 1× placeholder for layout work and note the 2× spec for whoever produces the final asset. With srcset, you ship both and let the browser pick:
<img src="hero-600.jpg" srcset="hero-1200.jpg 2x" width="600" height="338">
Notice the width and height attributes riding along. They're what let the browser reserve the space before a single byte of the image loads — which is the next section's whole point.
Browsers read the width and height attributes on every img tag and compute the aspect ratio before loading the file. With attributes present, the box is reserved at the correct size on first paint; without them, the browser guesses, gets it wrong, and the page reshuffles when images arrive. Placeholders make honoring this rule easy during development, when the real images don't exist yet. In CSS, aspect-ratio: 16/9 on a container does the same job for background and fluid slots — pair it with the placeholder at the same ratio and you've verified the reservation works. One caveat: never lazy-load the hero. loading="lazy" belongs below the fold, where deferred loading costs nothing; a lazy hero delays your Largest Contentful Paint for no benefit.
Any width, height, and colors — rendered in your browser, downloadable as PNG, with the dimensions printed right on the image.
Placeholder Image Generator →URL placeholder services are convenient — drop a URL into your HTML and an image appears — but they add a third-party dependency, rate limits, and a hotlinked request that can slow local development or leak browsing context. Generating placeholders yourself, the way the placeholder image generator does it in-browser, keeps everything local: no network call, no tracking, works offline, and the PNG is yours to commit into the repo next to the code that needs it. A reasonable middle path: use URL services in throwaway demos, generated files anywhere the mock might be screenshotted, versioned, or shown to a client.
Size the placeholder to the slot, the slot to its ratio, and the ratio to its job — social previews at 1200×630, heroes at 16:9, email at 600 wide, and a 2× companion for everything that matters. Always write width and height attributes so the browser can reserve the space, and keep a low-busy center if text will overlay the final image. When photography is ready to replace scaffolding, the image cropper cuts the real assets down to the spec your placeholders already proved out.
Yes — that's the entire point. The placeholder should match the final slot's exact width, height, and aspect ratio so nothing shifts when the real asset arrives. A placeholder at a different ratio tests the wrong layout.
1200 × 630 pixels is the safest social link-preview size across Facebook, X, and LinkedIn. Generate a 2400 × 1260 version as well if you want retina-sharp previews when the real image lands.
High-density screens pack two physical pixels into each CSS pixel, so a 600 × 400 CSS slot needs a 1200 × 800 file to render sharp. The 2x file is displayed at the same visual size, just with twice the pixel density.
Not while they're placeholders — a solid-color PNG is a few hundred bytes. They affect speed indirectly, by forcing you to reserve layout space with width and height attributes, which prevents cumulative layout shift when the heavy real images load.