Placeholder and Dummy Images — Generating the Right Stand-in Every Time

The placeholder's entire job is occupying a layout position at the final asset's dimensions, and the common failure is eyeballing a box. The real inventory you should generate once and keep as a set: 1920×1080 hero, 1200×630 social/OG image, 800×800 product tile, 400×400 avatar, 160×160 thumbnail, 1080×1920 story/mobile hero, 300×250 and 728×90 for ad slots — every one of them a real ratio that changes the layout it lives in.

The bug-catching value is concrete: a 4:3 image in a 16:9 container is where 'the card is too tall', 'the grid wraps weird on tablets' and 'the caption overlaps on mobile' come from, and the placeholder is the cheapest way to see it before the real shoot is booked. Generate the set at exact sizes; reuse forever.

PNG is the correct default: it preserves the requested dimensions exactly, stores flat colour without the ringing artefacts JPEG puts around edges, and supports transparency when the placeholder should show a background instead of its own grey. The conventional greys are mid-neutral (#CCCCCC classically) because the stand-in must not compete with the design around it — and because a placeholder in the brand's colour reads as content and gets praised in the review.

A tasteful upgrade with real usability: two-tone with the text label — grey box, darker label, slot name. Clients reading a mockup ask 'what goes here?' about every anonymous image; a labelled placeholder answers before the question, which is the entire difference between a mockup review and a mockup meeting.

The classic pattern is a service URL in the markup — placehold.co-style endpoints with the size in the path, rendered on demand, cached by the browser. It is convenient and it carries three real costs: your demo dies when the service does (or when the wifi does — pitch-deck offline mode is where URL placeholders go to be embarrassing), the requests leak your mockup's structure to a third party, and the image weight and timing are outside your control.

Locally generated placeholders — a file created in your browser tab and saved to the project — pay none of those. They ship with the repo, load from the same origin, work on a plane, and survive into the final product as nothing, because they are just files that the real assets replace by name. For client-confidential work (unannounced products under NDA) the no-upload property is not a nicety; sending a project's layout skeleton to a third-party render service is the disclosure.

For self-contained demos — single-file HTML, email templates, CodePen mockups, fixtures in tests — the placeholder's best form is a data URI: generate the image, convert it to Base64, and the stand-in lives inside the markup with zero external files. A 2 KB placeholder at the slot's exact ratio is invisible to layout and immortal in a single file.

And the pattern worth stealing from design tools: the CSS aspect-ratio box — background-colour plus aspect-ratio: 16/9 on the container — replaces the image entirely for layout work, since the browser reserves the space with no asset at all. It is the right answer when the grey is only structural; the moment a stakeholder needs to see 'the image area', a labelled placeholder communicates what a CSS rule cannot.

Avatar circles, rounded cards and hexagonal profile frames are layout-specific enough to need their own placeholders: generate at the full slot size, then apply the circle-crop or rounded-corners tool so the stand-in shows the mask's real geometry. An avatar placeholder that ignores the circular crop is exactly the file that hides the 'your logo gets cut off at the corners' surprise until the assets ship.