Free Placeholder Image Generator

How It Works

1. Set dimensions: Enter the width and height in pixels for your placeholder image.
2. Customize appearance: Choose background color, text color, and the label text to display (or leave blank for the dimension label).
3. Use or download: Copy the image URL for use in HTML/CSS, or download the PNG directly for mockups and designs.

Why Use Placeholder Image Generator?

During web development and design mockups, you often need images before the real content is ready. Placeholder images fill space in layouts to show proportions, test responsive behavior, and communicate design intent to clients. Instead of searching for stock photos or creating blank images manually, this tool generates properly-sized placeholders instantly with your chosen dimensions and colors.

Features

• Custom dimensions: Any width and height in pixels, square, portrait, landscape, or banner sizes.
• Color customization: Set background and text color using hex codes or color pickers.
• Custom label text: Display any text on the image, or default to the dimension label (e.g., 400×300).
• Instant URL: Get a data URI that can be pasted directly into src attributes for testing.
• PNG download: Download the generated placeholder as a PNG file for use in design tools.

Frequently Asked Questions

Can I use this in HTML src attributes?

Yes. The generated image is available as a data URI that you can paste directly into an <img src=""> attribute in your HTML. No hosting or external URL needed.

What sizes are common for placeholder images?

Common sizes include: hero images (1200×630), blog thumbnails (400×300), avatars (100×100), Open Graph images (1200×628), and banner ads (728×90). Enter any custom size for your specific layout needs.

How do I use placeholder images in CSS?

Copy the data URI and use it as a CSS background: background-image: url("data:image/png;base64,..."). This works in all modern browsers and requires no external files.

A short history of placeholder image services

Placeholder image services emerged in 2010 when web designers needed a quick way to fill mockups before final assets arrived. placehold.it, launched by Dave Reilly in 2010, was the first widely-used service: paste a URL like placehold.it/300x200 in any <img> tag and get a grey rectangle. placekitten.com followed the same year, replacing rectangles with random kittens, and dummyimage.com (Russell Heimlich, 2010) added colour customisation. Whimsical variants proliferated: fillmurray.com (Bill Murray photos, 2013), placebeard.it (beards, 2014), placecage.com (Nicolas Cage). The serious successors arrived later: Lorem Pixel (defunct around 2017) and Lorem Picsum by David Marby (2018), which serves random photos from Unsplash at any size. Around 2014, Facebook popularised the «skeleton screen» pattern: showing grey shapes where content will load. By 2019, Wolt released BlurHash, a 20-byte string that decodes to a low-resolution blurred placeholder of the real image. Today, ThumbHash (Evan Wallace, 2023) and the native aspect-ratio CSS property (Chrome 88, January 2021) let you reserve image space without external services at all.

Standard image sizes worth memorising

• Open Graph (1200×630). The canonical link-preview size defined by Facebook's Open Graph protocol. LinkedIn, Slack, Discord, Twitter (when no Twitter Card is set) all fall back to this. Aspect ratio 1.91:1.
• Twitter Card summary_large_image (1200×675). 16:9 ratio for in-feed previews. The 1200×628 you see quoted is the older standard, replaced by 1200×675 in 2023.
• Instagram (1080×1080 square, 1080×1350 portrait, 1080×1920 story). Anything above 1080 wide gets downsampled. Story aspect ratio is 9:16.
• YouTube thumbnail (1280×720). 16:9. YouTube auto-generates these from video frames; uploaded custom thumbnails must be under 2 MB.
• IAB ad sizes. The Interactive Advertising Bureau standardised banner dimensions: 728×90 (leaderboard), 300×250 (medium rectangle, the most-bought size globally), 300×600 (half page), 160×600 (wide skyscraper), 320×50 and 320×100 (mobile).
• Favicons. 16×16 and 32×32 for browser tabs, 180×180 for Apple touch icons, 192×192 and 512×512 for Android manifest.json, 512×512 minimum for PWA install prompts.
• Email headers (600×200). Most email clients cap rendered width at 600 px. Going wider gets squashed or scrollbars appear in Outlook desktop.

Placeholders and Core Web Vitals

Google's Core Web Vitals (launched May 2020) measure user experience and feed into search ranking. Two of the three metrics depend directly on how you handle images. CLS (Cumulative Layout Shift) penalises content that jumps as the page loads. The most common cause: an <img> without explicit width and height attributes, which gives the browser zero space to reserve until the image finishes downloading. A score above 0.1 fails the metric. The fix is trivial: always set width and height, even on responsive images, so the browser can compute the aspect ratio. LCP (Largest Contentful Paint) measures when the biggest visible element loads. For most pages that element is the hero image. Anything over 2.5 seconds fails. Strategies: serve modern formats (WebP, AVIF), use loading="lazy" on below-the-fold images (Chrome 76, August 2019), and use fetchpriority="high" on the hero. Placeholders bridge the gap visually: skeleton screens for layout, BlurHash or ThumbHash for an instant preview of the actual image colour palette.

Image format decision guide

• PNG (1996). Lossless, supports transparency, no patent issues. Best for logos, icons, screenshots, graphics with sharp edges. Indexed-colour PNG-8 (256 colours) is dramatically smaller than RGB PNG-24 and often invisible for UI icons.
• JPEG (1992). Lossy, no transparency, optimised for photographs. Quality 75-85 is the sweet spot for the web; visually indistinguishable from quality 95 at half the size. Avoid JPEG for anything with sharp edges (text, logos): you get visible ringing artefacts.
• WebP (Google, 2010). 25-35% smaller than JPEG at the same visual quality, also smaller than PNG for lossless. Supports transparency, animation, both lossy and lossless modes. Browser support: 97% as of 2024. Default choice for new sites.
• AVIF (Alliance for Open Media, 2019). Based on AV1 video codec. Roughly 50% smaller than JPEG, 20% smaller than WebP. Higher CPU cost to encode. Browser support: ~93% as of 2024, missing on older Safari. Use behind a <picture> fallback.
• SVG. Vector. Scales infinitely without quality loss. A logo in SVG is often 500 bytes versus 10 KB as a 512×512 PNG. Inline SVG in HTML avoids an extra HTTP request entirely. Don't use for photographs.
• Data URI. data:image/png;base64,... embeds the image bytes directly in HTML or CSS. Saves an HTTP request at the cost of inflating the surrounding file by ~33% (base64 overhead). Worth it for tiny placeholder thumbnails, never for hero images.

Where placeholder images actually get used

• Wireframes and mockups. Figma, Sketch, Adobe XD, Penpot all support drag-and-drop placeholder images. Designers sketch layouts before art direction lands, using grey rectangles or the dimension text as visual placeholders.
• Skeleton screens. Twitter, Facebook, YouTube, LinkedIn all show grey block placeholders while content loads. Research from Luke Wroblewski (2013) shows skeleton screens make perceived load time feel up to 20% faster than spinners.
• Design system stories. Storybook, Histoire, and Ladle render component previews that need stand-in images. A consistent placeholder set makes screenshots reproducible across CI builds.
• Email mockups. Litmus, Email on Acid, Mailchimp template builders. Email clients vary wildly in image support (Outlook desktop, Gmail web, iOS Mail), so designers test with placeholders before swapping in production assets.
• Print proofs. Book layouts, magazine pages, and packaging designs use FPO («for position only») placeholders during typesetting. The dimensions live in the layout long before the photographer delivers.
• Tutorials and documentation. When writing «how to build a card component», you need image stand-ins that won't break if the source changes. Self-hosted placeholders survive when external services shut down (like Lorem Pixel did).
• A/B tests and prototypes. Quickly testing layouts with three different image sizes is faster with generated placeholders than re-rendering real assets.

Mistakes that hurt page performance

• Forgetting width and height attributes. The single most common cause of poor CLS scores. Even with CSS-driven responsive images, set the intrinsic width and height so the browser reserves the right aspect ratio. Modern browsers compute aspect-ratio: width/height automatically from these attributes since 2020.
• Serving 4096×4096 placeholders for 200×200 displays. Twenty times the bytes for no visual benefit. Match placeholder dimensions to actual rendered size, or use srcset with multiple variants.
• Empty or missing alt text. Screen readers announce «image» with no context. For purely decorative placeholders, use alt="" explicitly to signal «skip this». For content images, write the description even on placeholders so QA catches missing copy.
• Inlining huge data URIs. A 100 KB image as base64 becomes ~133 KB inside your HTML, blocks parsing, and ruins caching (HTML usually isn't cached aggressively, images are). Use data URIs only under ~2-4 KB.
• Depending on placehold.it / lorempixel / external services in production. They go down. Lorem Pixel disappeared around 2017 and broke thousands of demo sites. For tutorials, demos, and stories, generate placeholders yourself or self-host them.
• PNG for photographs, JPEG for logos. A photo as PNG is 3-5x larger than the same image as JPEG. A logo as JPEG gets ugly compression rings around the edges. Pick format by content type, not habit.
• Skipping loading="lazy". Below-the-fold images that load eagerly compete for bandwidth with the hero. Add loading="lazy" to everything below the viewport. Native, no library needed, supported since Chrome 76 (August 2019) and Safari 15.4 (2022).

More frequently asked questions

Why is the dimension label so useful on a placeholder?

When you have a dozen placeholders in a layout at different sizes, the label tells you immediately which slot is which. «400×300» on a grey rectangle is more informative than guessing whether a card is 4:3 or 16:9. Designers and developers reviewing a mockup can spot mis-sized elements from across the room.

What's the difference between BlurHash, ThumbHash, and LQIP?

All three encode a tiny preview of an image that decodes to a blurred placeholder. LQIP («low-quality image placeholder») is just a small JPEG (~100 bytes to 2 KB). BlurHash (Wolt, 2019) encodes any image into a 20-30 character ASCII string that you store in your database; decode time is microseconds. ThumbHash (Evan Wallace, 2023) is similar but 30-50% smaller for the same quality, and renders sharper edges. Modern frameworks (Next.js, Astro, Hugo) all support BlurHash out of the box.

Should I use SVG or PNG for placeholder thumbnails?

SVG if the placeholder is a simple shape (rectangle, icon, geometric pattern). A 50-byte inline SVG beats a 2 KB PNG every time. PNG if you need pixel-accurate text rendering or specific font fallbacks: SVG text rendering varies between browsers and platforms. For dynamic placeholders generated client-side, this tool produces PNGs because canvas text rendering is predictable across browsers.

Does the generated PNG include EXIF or hidden metadata?

No. PNGs generated by the HTML canvas toBlob() or toDataURL() APIs contain only the IHDR, IDAT, and IEND chunks plus a minimal tEXt chunk in some browsers. There's no GPS, no camera info, no editing history, no user identifier. Compare with phone-camera JPEGs that leak GPS coordinates and device serial numbers.

Is anything sent to a server when I generate an image here?

No. The image is drawn locally via the HTML5 Canvas 2D API in your browser. Open the Network tab in DevTools while generating: zero outbound requests for the image. Safe for confidential mockups, NDAs, client work, and unreleased product designs.