Placeholder Service — Tips & Tricks
Tricks for the Placeholder Service: using the URL scheme cleverly, caching and hotlinking, PNG vs. SVG, common pitfalls, and combining it with other JPKCom tools.
Back to the overview: Placeholder Service · Open the tool live: www.jpkc.com/tools/ph/
The manual explains every option, the examples show the workflows. This page is about what both assume but rarely state: how to use the URL scheme efficiently, when PNG and when SVG is the better choice, and which quirks trip people up. The interface is in English, so the real card and button names appear in their original spelling.
Using the URL scheme cleverly
- You don't need the interface. Once you know the pattern
?WIDTHxHEIGHT-BACKGROUND-TEXTCOLOR/, you type placeholder URLs straight into your markup or template. The tool is then only there for quick experiments and picking colours. - Generate placeholders in loops. Because each size and colour is its own URL, you can vary them systematically in a template loop — e.g.
…-Image+1/,…-Image+2/for a gallery. Dimensions and colours stay the same; only the text counts up. - Colours without
#. In the URL scheme hex values appear without the hash (cccccc, not#cccccc) and must be exactly six digits. Three-digit shorthand (ccc) doesn't work here. - Spaces are
+. In the custom text,+becomes a space. For "Hello World" you writeHello+World.
Caching and hotlinking
- Images are cached for a year. The server sends
Cache-Control: public, max-age=31536000and a far-futureExpires. That's ideal for performance — the same placeholder URL loads from cache the second time. - That very caching can fool you. If you change an image at an identical URL, the browser may hold the old version. The interface works around this with a cache-buster on Update Preview — in real use you simply change a parameter (and thus the URL), and it's guaranteed to be a "new" image.
- Hotlinking is intended here — but mind the dependency. Embedding placeholders live from
jpkc.comties your page to this service. Fine for local mockups; for anything permanent, rather download the PNG or SVG and ship it, instead of linking out forever.
PNG or SVG — which when?
- PNG (server, URL scheme) is the right choice when you need a real image URL: for
<img src>, for tests, for anything that expects an address. It's a raster image at exactly the requested dimensions. - SVG (browser, SVG Output) is the right choice for CSS backgrounds and anything that should scale without quality loss. The data URI in
background-imagetriggers no network request and makes you independent ofjpkc.com. For Retina/HiDPI, SVG is superior anyway because it stays sharp at every resolution. - Remember: the URL scheme delivers PNG only. SVG is produced exclusively in the browser via the SVG Output card — there's no SVG URL the server serves.
Pitfalls from practice
- A broken URL returns HTML, not an error image. If an address doesn't fit the scheme (wrong number of parts, invalid colour, missing
xseparator), the server shows the generator interface instead of an image. In an<img>that appears as a "broken image". For a placeholder that won't load, check the URL structure first. - Umlauts and special characters disappear. The custom text allows only letters, numbers, and spaces server-side. "Café Müller!" becomes "Caf Mller" — umlauts,
&, punctuation are stripped. For mockups with umlauts the SVG variant is more reliable, because it carries the text as real markup. - The dimensions line can't always be switched off. Show resolution (or
nodim=1) only takes effect when a custom text is set. Without your own text the image must show the dimensions — otherwise nothing would be on it. The switch is deliberately disabled then. - Dimensions are hard-clamped. Values below 1 or above 3200 px are trimmed. If you need something larger than 3200 px per side, this service can't do it.
- The preview is deliberately manual. After each change you have to click Update Preview for the image preview to reload — the URL and code, by contrast, update immediately. That's not a bug; it saves server requests while you're still tweaking.
Use in HTML and CSS
- Always set
width/height. The<img>tag the tool produces brings both attributes. Keep them — they reserve the space and prevent layout shifts during loading (good for Core Web Vitals). - Responsive placeholders. Set the image to
max-width: 100%; height: auto, and a generously sized placeholder adapts to its container. For crisp, freely scaling fills, use the SVG data URI instead. - As meaningful
alttext. The tool fillsaltwith your custom text or "WxH placeholder". In a real mockup it pays to replacealtwith a description of the eventual image — then accessibility is already prepared before the real image arrives.
Combining it with other JPKCom tools
- From placeholder to real graphic: when the dummy should become the finished image, the Graphic Editor handles cropping, labelling, and exporting at the same target size.
- Finding the right hex values: with Color Tools you determine the background and text colour (including a contrast check) before you use them here — without the
#. - Dummy text for the same mockup: where placeholder images sit, the text is usually missing too. Lorem Ipsum supplies it to match.
More context: the overview for the big picture, the manual for the full URL scheme, and the examples for the step-by-step workflows. You can try everything right in the tool.