Placeholder Image Generator
Create custom placeholder images for mockups and wireframes. Set the size, colors, and label, preview live, then download a PNG or JPEG - nothing uploaded.
- Free, no account
- No watermark
- No usage limit
About the Placeholder Image Generator
A placeholder image is the gray box you drop into a layout while the real photo is still missing. This one makes it at any size you type, in your own background and text colors, with whatever label you want, then hands you a PNG or JPEG. It is free, there is no sign-up, and nothing gets uploaded.
What sets it apart from the placeholder services everyone reaches for first is boring and it matters: you get a real file on your own machine, not a URL pointing at somebody else's server. Type 300×200, hit Download, and a 300×200 file lands in your downloads a second later, yours to keep, drawn right there in the browser. It won't rate-limit you or vanish mid-demo, and it never reports which page loaded or what you're building back to a server you don't control.
How to use
- Type a width and height in pixels. Defaults are 300×200. Change them to the slot you're filling. Anything over 4000 on a side gets capped, and the tool tells you when it did.
- Set the colors. Click a swatch for the picker, or paste a hex code into the field beside it. Background and text are separate, so you can match a client's palette or keep the plain gray-on-gray.
- Add a label, or leave it blank. Blank shows the dimensions ("800×600"). Type "Hero Image" and that wins instead. The text auto-shrinks so a long label never spills off the edge.
- Watch the preview redraw as you type. It scales down on screen for big sizes, the download is always full resolution.
- Pick PNG or JPEG and download. The file saves as
placeholder-800x600.png(or.jpg).
Skip the typing with the preset buttons for the sizes you reach for constantly, avatar, card, social banner, 16:9, hero. And there's a Swap W/H button for the classic moment you meant landscape and keyed in portrait.
Why a downloaded file beats hotlinking a placeholder URL
A placeholder URL is a live dependency you bolted onto your layout without meaning to. Every one of those image tags fires a request to a server you don't control, and that server has opinions. It can rate-limit you when you refresh a gallery twenty times an hour. It can be slow, a lookup plus a connection plus a download, multiplied by every placeholder on the page, so your prototype feels laggy for no reason at all. The service can also disappear from under you. The old default everyone hardcoded for years, via.placeholder.com, got unreliable enough that placehold.co exists partly to replace it, and projects that had baked the dead URL into their templates were left showing broken-image icons. A file you downloaded can't be deprecated out from under you.
Then there's the part that actually matters when you build for other people. Every placeholder URL request quietly tells that third-party server which page loaded, when, and from what address. For a public marketing splash, fine, nobody cares. For a client's unreleased product, an internal admin panel, anything under an NDA, you probably don't want the shape and structure of your unbuilt interface phoning home to some analytics dashboard you've never read. Generating locally means nothing goes out at all, so the sizes you type, the colors you pick and the labels you write never leave the tab. That by itself is reason enough to keep a real file in the repo instead of a hotlink in the source.
When does the URL still win? One case, an inline example you're not going to host, a quick CodePen, a throwaway answer on a forum, where committing a file is more hassle than it's worth. For that, a URL is genuinely the right call. The moment you're building something that lives in a repo and ships, you want the file.
Match the shape your real images will use
A placeholder's only job is to behave like the real image that's coming, and half of behaving like it is having the right shape. Test a 16:9 photo slot with 1:1 gray squares and you've quietly hidden every cropping, stretching, and overflow bug the real photos will cause. Then they all surface on the day you swap the real assets in, which is the worst possible day to find them. Match the aspect ratio you'll actually ship.
The sizes you'll type most often:
| Slot | Width × Height | Ratio |
|---|---|---|
| Avatar | 200 × 200 | 1:1 |
| Card image | 400 × 300 | 4:3 |
| OG / social share | 1200 × 630 | ~1.9:1 |
| YouTube thumb | 1280 × 720 | 16:9 |
| Hero banner | 1920 × 1080 | 16:9 |
The 1200 × 630 one is worth memorising. It's the size link-preview cards ask for, so it's the shape of almost every "share this" image you've ever seen scroll past in a chat.
One more, cheap habit: label the slot, not the size. "300×200" is accurate but empty. Set the label to "Product Photo" or "Author Headshot" and a design review reads like a real page instead of a wall of identical boxes nobody can tell apart. Costs nothing, and it saves you explaining out loud what each gray rectangle is supposed to become.
Frequently asked questions
PNG or JPEG, which should I pick?
PNG, almost always. A placeholder is flat color and hard-edged text, which is exactly what PNG stores efficiently, so even a large one is a few kilobytes and the letters stay razor sharp. JPEG is built for photographs, so point it at solid color and crisp text and it smears faint fuzz around the letters and can't hold a truly clean block. Only choose JPEG if something downstream flatly demands a .jpg.
Can I make a transparent placeholder?
Not with a solid fill, no. Filling the rectangle with a color is the entire point of a placeholder, so it can't be see-through and colored at once. If you actually need transparency (a shape that shows whatever sits behind it), that's a different job, an empty image with no fill, not this one. For the standard gray-box-the-right-shape task, a solid PNG is what you're after.
Why is the size capped at 4000 pixels?
Browsers put a real ceiling on how large an image they'll build on a page, and it varies by device. Push past that limit and the image can come back blank with no warning at all. Capping each side at 4000 keeps every generation quick and guarantees you get an actual file instead of a mystery blank. For any normal slot that's already two or three times the display size, so high-density screens are covered.
Do I need to generate bigger for retina screens?
If you want the label crisp on a modern display, yes, a bit. High-density screens pack two or three physical pixels into each CSS pixel, so a placeholder made at its exact CSS size gets stretched and the text goes soft, which reads as "unfinished" in a review even on a gray box. Generate at double the slot size, an 800 × 600 file for a 400 × 300 card, and let the page shrink it back. Flat color compresses so well that doubling the pixels barely moves the file size.
The preview looks smaller than the size I typed. Is the file wrong?
No, the file is exactly what you asked for. The preview shrinks to fit the page when you request something large, and it shows you the scale it's using ("preview scaled to 30%"). The saved image is always the full pixel dimensions you entered, so a preview that looks tiny on screen still downloads at the size you set.
Is anything I type sent anywhere?
No, and that's the whole point. Width, height, colors, and label all stay in the browser, the file is built and saved locally, no requests go out. It keeps working with your wifi off, and your unreleased work never leaks its layout to a third party the way a hotlinked placeholder service does.
Can I leave these in the live site?
Please don't. Placeholders are scaffolding, they hold the space until the real content shows up. Ship one and you've got a live page announcing "800×600" where a product shot belongs, with no alt text for screen readers or search engines either. Generate as many as you like during the build, then clear every one out before launch.