Placeholder Image Generator
Create placeholder images at any size with custom colours and label text, generated locally rather than fetched from a remote service.
The default download is 1.4 megabytes of pixels and about 2 kilobytes of file
An 800 × 600 image holds 480,000 pixels at three bytes each — 1.37 MB before anything is done to it. Encoding it as a real PNG, header and filtered scanlines and checksums and all, comes to 2,316 bytes. These figures are measured by building the files, not estimated:
| Size | Pixels | PNG bytes | Compression | Bytes per 1,000 pixels |
|---|---|---|---|---|
| 100 × 75 | 7,500 | 179 | 126:1 | 23.9 |
| 400 × 300 | 120,000 | 819 | 440:1 | 6.8 |
| 800 × 600 | 480,000 | 2,316 | 622:1 | 4.8 |
| 1600 × 1200 | 1,920,000 | 8,462 | 681:1 | 4.4 |
| 3200 × 2400 | 7,680,000 | 27,822 | 828:1 | 3.6 |
The last row has 1,024 times the pixels of the first and only 155 times the bytes, and the cost per pixel keeps falling all the way down the table. Part of that is fixed overhead — signature, header chunk, checksums — becoming a smaller share each time; the rest is that a longer run of identical bytes compresses better than a short one. Which is why placeholder services can serve any dimensions you ask for without caring: the HTTP request costs more than the image.
Size is not what makes an image big
Keep the dimensions and replace the flat colour with random noise:
| Size | Flat | Noise | Multiple | Bytes per pixel |
|---|---|---|---|---|
| 100 × 75 | 179 | 22,648 | 127× | 3.02 |
| 400 × 300 | 819 | 360,473 | 440× | 3.00 |
| 800 × 600 | 2,316 | 1,441,086 | 622× | 3.00 |
The noisy files land on exactly three bytes per pixel at every size — precisely the raw cost of three colour channels. Random data cannot be compressed, so the encoder stores it verbatim and adds its own bookkeeping on top: the 800 × 600 noise file is 1,441,086 bytes against 1,440,000 bytes of actual pixels. Encoding it as a PNG made it bigger.
The multiple grows rather than shrinking, because the noisy files are pinned at three bytes a pixel while the flat ones keep getting cheaper. Set the two extremes against each other: a noisy 100 × 75 thumbnail costs 22,648 bytes, and a flat 3200 × 2400 image — a thousand times as many pixels — costs 27,822. PNG stores the surprise in an image, and a flat rectangle contains none.
Turn a PNG on its side and the file size changes
PNG filters each row against the row above it, so the format treats the two axes differently. The same gradient, running across or down:
| Size | Flat | Horizontal | Vertical | Dearer |
|---|---|---|---|---|
| 200 × 200 | 435 | 876 | 487 | horizontal by 80% |
| 400 × 400 | 1,059 | 1,613 | 1,254 | horizontal by 29% |
| 800 × 600 | 2,316 | 2,862 | 3,168 | vertical by 11% |
| 800 × 800 | 3,057 | 3,603 | 4,824 | vertical by 34% |
Neither direction is universally cheaper, which is the part worth knowing. A horizontal gradient varies along each row but every row is identical, so after filtering everything below the first row is zeros — it pays once, for that first row, and about 550 bytes covers it at any width. A vertical gradient is flat along each row and steps down the image, so it pays a little at every row where the value changes, and that bill grows with height.
Below roughly 400 rows the one-off cost dominates and horizontal is the expensive direction; above it the per-row cost takes over and vertical is. At 200 × 200 the horizontal version is 1.8 times the vertical one, and at 800 × 800 the vertical is 1.34 times the horizontal. Same gradient, same pixel count, and rotating it changes what it weighs.
How to use
- Set the dimensions your layout actually needs.
- Choose colours and the label text.
- Download the file, or copy it as a data URI.
- Test with awkward sizes as well as tidy ones.
- Replace every placeholder with real imagery before shipping.
Frequently asked questions
Why generate placeholders locally rather than using a service?
Because a remote placeholder service becomes an external dependency inside your page. Several popular ones have gone down or disappeared over the years, breaking every mockup that referenced them, and each request also leaks who is viewing your prototype and when.
What should the label say?
The dimensions, usually — seeing 800 by 600 written across the image itself makes layout debugging considerably faster than measuring anything. Adding a short note of what the image is meant to become helps whoever else reads the mockup later.
Do placeholders hide layout problems?
They can, and it is worth being aware of it. Placeholders are always exactly the size you requested, whereas real images arrive at unexpected proportions, load slowly, and sometimes fail entirely. A layout tested only against perfect rectangles frequently breaks on real content.
Should placeholders look obviously fake?
Yes, deliberately so. A placeholder resembling a real photograph can ship unnoticed, which has happened on live sites and printed material more than once. A flat grey rectangle with its dimensions written on it is impossible to mistake for finished work.
What sizes should I test with?
Several, including deliberately awkward ones. A very wide image, a very tall one and a tiny one together expose layout assumptions that a neat set of identical rectangles never will, and finding those before launch is the entire point of a mockup.
Does anything get uploaded?
No. The image is drawn in your browser and downloaded directly, so no request is made to any external service at any point.
Can I use these in production?
Only as a deliberate fallback — a grey rectangle where a user has not uploaded an avatar, for instance. Shipping placeholders in place of content you intended to supply is the failure mode the obvious styling is meant to prevent.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.