The Best Image Size for a Cold Email Is Usually No Image
2026-09-03 · Julian Hartwell
The best image size for a cold email is often no image at all unless the visual carries decision-critical proof that the recipient cannot infer from concise text. The safest default is a text-only cold email. Add an image only when it carries decision-critical proof that concise words cannot communicate, and make the message understandable when images are blocked.
Answer the prior question: should the email contain an image
For most first-touch cold emails, start with no image. A decorative banner adds load, rendering, accessibility, and attention costs without helping the recipient decide. Consider a visual only when it carries proof that concise text and a normal link cannot communicate as clearly, such as a tightly cropped product state or annotated result the recipient specifically needs.
- State the visual’s decision job in one sentence.
- Remove it if the email remains understandable without it.
- Never put the only explanation or call to action inside the image.
- Prefer a link to richer proof when the visual would dominate the message.
- Send the proof-bearing version and a text-only control to internal test accounts over both constrained and normal network conditions; log whether loading delay changes the order in which the recipient encounters the argument.
- Inspect the asset at 100 and 200 percent zoom. If the evidence becomes illegible or the layout breaks, replace the visual with concise live text or a link to an accessible source.
No pixel number rescues an unnecessary visual
Width and file size become relevant only after the image earns a place. Choosing dimensions first encourages decoration to masquerade as evidence. A laboratory supplier first proposes a decorative hero image, but it adds no evidence beyond the text. The reviewer removes it and keeps only a calibration diagram whose labels help the recipient judge equipment compatibility.
Choose dimensions from the reading column
If a visual is necessary, size it for the email’s actual content column and mobile behavior rather than a desktop design canvas. Keep the source clear at the rendered width, preserve aspect ratio, and avoid relying on exact pixels across clients. The user asked for size, but the defensible answer is a bounded rendering test rather than a universal number.
- Export one version that stays legible at the narrow mobile column.
- Keep important labels large enough to read without zooming.
- Compress the asset while checking that proof details remain intelligible.
- Avoid a tall image that pushes the text and opt-out path below the fold.
- Use OKKI Go for the surrounding human-reviewed draft, not as evidence that an image will render everywhere.
- Send the proof-bearing version and a text-only control to internal test accounts over both constrained and normal network conditions; log whether loading delay changes the order in which the recipient encounters the argument.
- Inspect the asset at 100 and 200 percent zoom. If the evidence becomes illegible or the layout breaks, replace the visual with concise live text or a link to an accessible source.
Treat file weight as part of size
Pixel dimensions describe geometry; bytes affect loading. A compact image that retains its evidentiary detail is usually safer than a large high-resolution export. Record both before testing. The diagram is exported to fit the tested reading column without scaling its labels below legibility. The team records pixel dimensions and bytes separately, because visual width and download weight create different failure modes.
Design for blocked and inaccessible states
Many recipients will see a blocked image, a slow load, a clipped preview, or a screen-reader interpretation. Write useful alt text that conveys purpose without repeating the entire email, and keep the core proposition in live text. If the image contains dense numbers, provide the relevant conclusion in prose.
- Turn images off and read the message from top to bottom.
- Check that alt text names the proof rather than saying “image.”
- Verify that links and the call to action remain visible.
- Inspect contrast and legibility in light and dark display modes.
- Do not use tracking observations as proof that a person understood the visual.
- Send the proof-bearing version and a text-only control to internal test accounts over both constrained and normal network conditions; log whether loading delay changes the order in which the recipient encounters the argument.
- Inspect the asset at 100 and 200 percent zoom. If the evidence becomes illegible or the layout breaks, replace the visual with concise live text or a link to an accessible source.
Alt text is a fallback, not a duplicate canvas
A concise alternative should preserve the decision-relevant meaning. It does not need to recreate every decorative detail, and it should not become another sales paragraph. With images blocked, the email still states the compatibility conclusion and links to an accessible document. Alt text identifies the diagram's purpose without recreating an entire sales pitch or hiding the decision inside the asset.
Test the clients your recipients use
Render the same message in a representative mix of desktop, mobile, webmail, and image-blocked conditions. Check scaling, clipping, orientation, dark-mode treatment, load delay, and link behavior. Sender guidelines from Google and Yahoo focus on authentication, complaints, opt-outs, and message-stream practices; image sizing does not replace those system controls.
- Capture screenshots at the tested viewport.
- Record client, operating system, and test date.
- Compare the visual version with a text-only control.
- Use delivered recipients as the experiment denominator.
- Pause if the asset causes clipping or obscures required information.
- Send the proof-bearing version and a text-only control to internal test accounts over both constrained and normal network conditions; log whether loading delay changes the order in which the recipient encounters the argument.
- Inspect the asset at 100 and 200 percent zoom. If the evidence becomes illegible or the layout breaks, replace the visual with concise live text or a link to an accessible source.
Rendering evidence expires
Client behavior changes. A passing screenshot from an old template is not evidence for a new export, new layout, or new client version. The first mobile client clips two labels, while the desktop client displays them correctly. The asset returns for a simpler crop and is retested in the actual template; the old screenshot cannot validate the new export.
Keep the cold email complete without the asset
Before release, read the subject, opening, proof, next step, sender identity, and opt-out path with the image unavailable. The FTC, ICO, Google, and Yahoo requirements remain applicable according to jurisdiction, recipient, and sender scope. OKKI Go can support a reviewed draft, while the sender remains responsible for those choices and the visual test.
- Confirm accurate sender and subject information.
- Retain a clear reason for contact in live text.
- Place the next step outside the image.
- Honor suppression and opt-out handling.
- Document why the visual was included and when it will be retested.
- Send the proof-bearing version and a text-only control to internal test accounts over both constrained and normal network conditions; log whether loading delay changes the order in which the recipient encounters the argument.
- Inspect the asset at 100 and 200 percent zoom. If the evidence becomes illegible or the layout breaks, replace the visual with concise live text or a link to an accessible source.
The useful size rule
Use no image by default. When a proof-bearing visual is essential, make it only as wide, tall, and heavy as needed to remain legible in the tested reading column, with a complete text fallback. That rule travels better than a magic pixel value. The final email remains complete without loading the diagram and uses the smallest tested asset that preserves the proof. If later copy makes the visual redundant, the default decision returns to no image rather than protecting a magic size.
Keep first-touch cold email text-only unless a visual is the only way to show decision-critical proof, and make the message readable when that file never loads.
Frequently asked questions
Should a first-touch cold email include an image?
The default is no. A banner adds load, rendering, and accessibility cost without helping the recipient decide. Add a visual only when it carries proof that concise words cannot.
If an image is necessary, how should it be sized?
Size it for the email content column and mobile rendering, not a desktop design canvas. Keep the source recognizable when images are blocked.
What rendering test should precede send?
Open the same message on desktop, mobile, webmail, and image-blocked views. Check scaling, clipping, dark-mode treatment, and whether the next step still reads without the file.
Does a pixel range replace the legal and identity checks?
No. Subject accuracy, sender identity, and opt-out still apply when a visual is present. The image cannot carry a promise the text does not keep.