Placeholder Image Generator: Exact Sizes for Mockups and Prototypes

Every project hits the same gap: the layout is ready, the real photography is not. You have a card that wants a 600×400 image, an Open Graph slot that wants 1200×630, and a hero that wants 1920×1080 — and none of those assets exist yet. The fastest way to keep moving is a stand-in image at the exact size of the slot, with the dimensions printed right on it so nobody on the team mistakes a draft for the finished thing.

That is the entire job of a placeholder image generator. You pick a width and a height, and the image renders at exactly that size with the dimensions printed on it. You can run it from the Placeholder Image Generator without installing anything, and the pixels never leave your browser tab.

Why exact dimensions matter more than they look

A placeholder is not just gray filler. Its job is to occupy the precise box your CSS or your Figma frame reserves, so the layout behaves the way it will behave with real content. If you drop a square image into a slot meant for a 3:2 card, the grid reflows wrong, the aspect ratio lies to you, and you "fix" a layout that was never broken.

Printing the size on the image solves a second, quieter problem. When a stakeholder scrolls a 12-screen prototype, a frame that reads "750×1334" tells them at a glance that the slot is intentional and correctly proportioned. A blank gray box invites the question "is this empty on purpose?" — and you spend the review answering it instead of getting feedback on the actual design. The label turns silence into a signal.

Matching the pixel size to the slot also keeps file weight honest. A 4000×4000 PNG for a 600px card preview is around 4 MB of wasted bytes; the browser scales it down on screen but never reclaims the cost on the wire. Generate at the size you need, not the largest size you can.

A worked example: a 600×400 card placeholder

Say you are building a content grid and each card holds an image above a title and a short blurb. The image slot is 600×400 (a clean 3:2). Here is the whole flow:

Set width to 600 and height to 400. The preview canvas redraws instantly.
Leave the label on auto and it fills in 600×400, or type your own — "Card draft" reads well in a review.
Pick a background and foreground with real contrast, like a dark slate fill #0F172A under light text #E2E8F0. Keep the ratio at 4.5:1 or better so the label never washes out.
Download a PNG and drop one file into every card while you build, or paste it straight into the Figma frame.

The grid now reflows exactly as it will with real photos, the cards read as deliberate rather than missing, and when the real art lands you swap one asset. No CDN round-trip, no rate limit mid-demo, no surprise when the slot turns out to be the wrong shape.

Why a local generator beats an external placeholder service

For years the default answer to "I need a placeholder" was a remote URL — you embed a link and a CDN renders a PNG on the fly. It works until it doesn't. The service gets slow, rate-limits you during a demo, gets blocked by a corporate firewall, or quietly shuts down. Two well-known placeholder hosts have disappeared in the last three years, taking every page that hard-coded their URLs down with them.

Generating locally removes the dependency entirely. The image is drawn in your browser with the Canvas API and saved as a file, so there are no calls to an external placeholder service baked into your mockup or your build. A few things fall out of that:

No network, so no flaky demos. A placeholder URL renders a gray box the instant the conference WiFi dies. A local file is real bytes on disk and looks identical whether you have 100 Mbps or zero.
No tracking and no leaked names. Your label text and brand hex codes are drawn on a local <canvas> and never sent anywhere. Confidential project names and NDA mockup labels stay on your machine — a remote service sees every request you make.
No third-party in the shipped file. Paste the generated image into Figma and it travels with the file. There is no live URL that can rot six months from now.

I switched to local generation after a launch demo where the venue WiFi throttled every outbound request and half my "images" rendered as broken boxes in front of the room. Now I generate the full set once, commit the files, and the prototype looks the same offline as it does on a fast connection. It is the kind of fix you make exactly once and never think about again.

SVG vs PNG (and the raster formats around them)

Placeholders come in two families, and the right pick depends on what consumes the image.

SVG is a vector format — a few hundred bytes of text that describe a rectangle and a line of text. It is resolution-independent, so the same file is crisp at 600px or 6000px, and it stays tiny no matter the dimensions. SVG shines when the placeholder lives inside your own front-end: a React component, a CSS background, or anywhere a browser renders the markup directly. You can even inline it as a data URI with zero extra requests.

PNG is a raster format — an actual grid of pixels, compressed losslessly. PNG is the safe universal choice: every tool, email client, and legacy Photoshop accepts it, and its lossless compression keeps the dimension label's text edges razor sharp. Reach for PNG when the image has to leave your codebase — pasted into a slide deck, attached to a brief, or handed to someone whose tool might not speak SVG.

The other raster options trade differently. WebP uses modern lossy compression and can land 5–10× smaller than the equivalent PNG for a flat-color placeholder, while looking identical; use it whenever a modern browser is the consumer. JPG is the one to avoid for labeled placeholders — its compression smears crisp text edges with artifacts, so save it for photographic fills only.

A simple rule: SVG when the placeholder stays inside the browser and scale matters, PNG when it has to travel and text sharpness matters, WebP when you want the smallest browser-ready file.

Fit it into a real workflow

Placeholders rarely travel alone. Once the layout is filled, the same throwaway-asset mindset shows up in adjacent tasks: building a gradient background for the hero you are still mocking, generating a favicon, or shrinking the real photos once they finally arrive with a local image compressor so the page that started as placeholders stays fast in production.

The throughline is the same one that makes local placeholders worth using in the first place: keep the work on your own machine, match every asset to the slot it fills, and never let a missing image be the reason a prototype reads as broken. Pick a width, pick a height, label it, and move on.

Made by Toolora · Updated 2026-06-13