What is a Placeholder Image?
Why placeholder images exist, how they're used in design and development, and what dimensions to use for common UI components.
What is a placeholder image?
A placeholder image is a temporary image used during the design or development of a product — in place of real content that either doesn't exist yet, hasn't been approved, or simply isn't available at that stage of the work. It occupies the correct space in a layout so that proportions, spacing, and visual flow can be evaluated without waiting for final assets.
In their simplest form, placeholders are solid grey rectangles with no content at all — just a box that says "an image goes here." More descriptive variants display the image dimensions as text (800×600) directly on the surface, which is useful when you need to communicate size requirements to a developer or client. At the other end of the spectrum, some teams use royalty-free stock photos as placeholders to give presentations a more polished feel while final photography is arranged.
The key characteristic of a placeholder is its temporary status — it is intended to be replaced before the product ships or the design is finalized.
Why use placeholder images?
Real projects rarely have all their assets ready at the start. Photography needs to be scheduled. Illustration takes time to commission. Meanwhile, the rest of the team — developers building the layout, designers iterating on the UI, stakeholders reviewing a prototype — cannot halt work waiting for a missing asset.
Placeholder images solve this by decoupling design and layout work from asset production:
- —Wireframing and prototyping — low-fidelity wireframes use grey boxes to represent images without implying specific content. This keeps feedback focused on layout and structure, not "I don't like that stock photo."
- —Frontend development — developers can build and test a layout with placeholder images long before the design team delivers final assets, and swap in real images at the end with a single file change.
- —Responsive design testing — testing how a layout responds at different breakpoints is easier when you have images at exact specified dimensions, rather than images that are the wrong aspect ratio and skewing the layout.
- —Client presentations — showing a half-finished page with broken image slots (alt text only, no visual) looks unfinished. A clean placeholder image keeps the presentation readable.
The UtilYard Placeholder Image Generator lets you set any width, height, background color, and label text, then download the image or use it as an inline data URL immediately.
Common placeholder sizes
The right size depends entirely on the UI component the image will fill. These are the standard dimensions used across web and app design:
- —Hero / full-width banner — 1200×630 or 1600×900 — hero images span the full page width. The 1200×630 size doubles as the standard for Open Graph social preview images. Use 16:9 (1600×900) for video-adjacent layouts.
- —Blog post / article thumbnail — 800×450 or 600×400 — 16:9 or 3:2 aspect ratios are conventional for editorial imagery. Most CMS platforms expect one of these.
- —Card image — 400×300 or 400×225 — product cards, blog listing cards, and app grid tiles typically use a 4:3 or 16:9 image at the top.
- —Square thumbnail — 400×400 or 300×300 — e-commerce product images, social media avatars in feed contexts, and music/podcast album art are conventionally square.
- —Avatar — 64×64, 128×128, or 256×256 — user avatars are nearly always square and rendered as circles in the UI. Provide at least 128×128 for retina displays.
- —Open Graph / social preview — 1200×630 — the exact dimension specified by the Open Graph protocol and used by Twitter/X, LinkedIn, Facebook, and Slack when unfurling link previews.
- —App icon — 512×512 — app stores require submission at 512×512. iOS and Android derive all smaller sizes from this master image.
When in doubt, match the aspect ratio of the final image rather than worrying about exact pixels. A layout built with a 16:9 placeholder will behave correctly when you swap in any 16:9 image, regardless of resolution.
Types of placeholders
- —Solid color boxes — the simplest form. A flat rectangle in grey or a brand color. Used in wireframes and low-fidelity mockups where visual detail would be distracting.
- —Dimension-labeled placeholders — a grey box with the width and height printed as text in the center (e.g., "800 × 450"). Immediately communicates the required size to anyone viewing the mockup. This is the format produced by tools like
via.placeholder.comand the UtilYard generator. - —Random stock photos — services like picsum.photos return a random real photograph at any specified size. These work well for high-fidelity prototypes where you want to test how real imagery interacts with text overlays and visual hierarchy.
- —Low-quality image previews (LQIP) — a technique used in production code. A tiny, heavily compressed version of the real image is loaded first, then replaced with the full image once it downloads. This gives users visual context immediately.
- —SVG-based inline placeholders — an SVG rectangle embedded as a data URI directly in HTML or CSS, requiring no external request. Useful for skeleton loading states shipped as part of the initial HTML.
When to switch to real images
Placeholders are a tool for unblocking work, not a permanent solution. These are the signals that it's time to replace them:
- —Before usability testing with real users. Participants need to evaluate the actual experience, including whether images communicate the right content. Grey boxes interrupt the illusion.
- —Before any public launch or beta. Shipping with visible placeholder images signals an unfinished product and damages credibility.
- —When testing SEO or social sharing. Search engines and social platforms index your
og:image. A placeholder will be indexed and shared — real images improve click-through rates. - —When evaluating visual design decisions. Placeholder images cannot tell you whether text will be readable over photography or whether the brand is being communicated effectively. High-fidelity decisions require real or near-real images.