The folder every designer knows
"We'll just send you the images." In eleven years as a designer, that sentence has cost me more nerves than any briefing. What actually turns up is rarely what the website needs: a ZIP with 300 phone photos, the logo as a screenshot out of a PDF, three versions of the same image at different quality levels, and a 40 MB "catalog" as individual JPGs. The raw material for the shiny new site is, first of all, a pile.
The same problems, every time
- Huge phone photos. 8–12 MP, 5–8 MB per image, straight out of the camera app. Looks great, and is wildly oversized for the web.
- The pixelated logo. No vector, just a 200-pixel JPG, often copied out of an old presentation — with a white box around it.
- Wrong color space. Images from a print workflow arrive in CMYK or Adobe RGB and suddenly look washed out in the browser. Why that happens is under sRGB, Adobe RGB & P3.
- Screenshots as content. Text as an image, often crooked, with compression artifacts — unreadable on Retina, a disaster for accessibility and SEO.
Why "send us the images" isn't enough
The fault rarely lies with the client. Nobody outside of design needs to know what dpi means, why a logo should be a vector, or that 300 phone photos together weigh half a gigabyte. That's exactly why the prep is my job — and the more clearly I structure it, the fewer rounds a project costs.
My intake workflow
I run every image delivery through the same process, instead of improvising file by file:
- Review & sort. First I separate the usable from the ballast. Duplicates, blurry shots, irrelevant images get tossed straight away — that pays off everywhere later.
- Check the technical side. A quick look at dimensions, format and file size shows what has substance. For that I run suspicious files through the Image Info tool— locally, no upload, which with someone else's material is also a data-protection question.
- Bring it to target size. Every image gets resized to the size it actually appears at — by far the biggest lever against slow load times.
- Format & compression. Photos to WebP/AVIF via the Converter, then compress with good judgment.
The most common emergency: the logo
No client material causes trouble as often as the logo. If it only arrives as a small pixel image, upscaling won't help — then it has to be rebuilt as a vector, or you have to ask the client for the original (AI, EPS, SVG). For the website, a logo practically always belongs embedded as SVG: crisp on every display, tiny in file size. Why that is, and when PNG is the better choice, is under SVG vs. PNG vs. JPG for icons.
What I hand the client
The best trick against the chaos folder is to get ahead of it. These days I give clients a short, uncomplicated set of instructions: send photos large and in their original form (better too much resolution than too little), please provide the logo as a vector file, and never put text in a screenshot. Those three sentences save both sides half the rework — and the rest I handle in prep, in minutes rather than hours.
Good client images are rarely a stroke of luck. They're the result of a clear process — and that process doesn't begin with the client, but with the question of how cleanly you take in the raw material.
Sources
web.dev — Serve images in modern formats · MDN — Image file type and format guide · W3C WAI — Images Tutorial.