Free · Fast · Privacy-first

Compress Image for Substack

Substack newsletters have to clear two completely different bars at once.

⚡

Faster Substack post load times

🔒

Reliable email delivery across clients

✨

Sharp rendering on every device

⚡

No watermark added

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Image Compressor to your website

Drop the Image Compressor into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/image-tools/image-compressor?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Image Compressor by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/image-tools/image-compressor?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Image Compressor by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why Substack image quality affects both the web post and the email version

Substack publishes each post in two places at once. The post page lives at a public web URL and gets indexed by Google and shared on social, while the email version goes to every subscriber inbox at publish time. Both versions reference the same hosted image files on the Substack CDN, but the rendering context is completely different. On the web, Substack serves responsive image variants through its CDN, including WebP for modern browsers, and the post page typically loads fast even with several inline images. In email, the rules are different. Most email clients still rely on the original JPEG or PNG source, do not run responsive variant selection, and aggressively cache the first version they render. The same uploaded image affects both contexts but with different optimization considerations for each.

The recommended workflow for Substack is to resize images to roughly 1456 pixels wide, which matches the Substack post body width on desktop and produces clean rendering on mobile through CSS scaling. Compressing at JPEG quality 80 to 84 percent produces files in the 200 to 400KB range that look sharp on the post page and load reliably in email clients including on slower mobile connections. Hero images at the top of a post benefit most from pre-compression because they are the largest contributor to Largest Contentful Paint on the web version and to email rendering time on mobile clients. Inline images further down the post matter less for LCP but still affect total page weight and email message size.

Substack email delivery is sensitive to total message size because some corporate spam filters flag messages above 5 or 10MB as suspicious, and some older email clients struggle to render messages above that ceiling at all. A Substack post with five inline photos at 4MB each produces an email message above 20MB that may not deliver reliably to every subscriber. Pre-compressing each image to under 400KB keeps total message size manageable, ensures consistent delivery across the subscriber list, and produces a snappy reading experience even on the older mobile clients that some long term subscribers still use. That reliability matters for newsletter engagement metrics that influence growth over time.

For Substack writers who publish heavy image content such as photography essays, travel writing, or visual journalism, the per image compression decision compounds across the publication. A weekly newsletter with ten inline photos per issue adds up to over 500 image uploads per year, and the difference between 4MB and 400KB per image translates to roughly 2GB of bandwidth saved per subscriber per year on the email version alone. For a publication with thousands of subscribers, the cumulative bandwidth and storage savings on the Substack side matter for platform reliability, and the cumulative subscriber experience improvement matters for retention and word of mouth growth that drives new signups.

Substack image and post formatting documentation Email image best practices (Litmus)

How to use this tool

💡

Upload your Substack image and set quality to 80 to 84 percent at 1456 pixels wide for clean web post and email delivery.

How It Works

Step-by-step guide to compress image for substack:

1
Resize to Substack post width
Use the FixTools Image Resizer to set the long edge to 1456 pixels, which matches the Substack post body width on desktop and produces clean rendering on mobile through CSS scaling. This is the sweet spot for both the web post and the email version of the post.
2
Open the Image Compressor
Drag the resized file into the FixTools Image Compressor. The compression runs locally in your browser, which matters for unpublished editorial photography and any subscriber exclusive content that should not pass through external services before reaching Substack.
3
Set quality to 80 to 84 percent
Drag the quality slider to a setting between 80 and 84 percent. For typical editorial photography at the Substack post width, that range produces files between 200 and 400KB that look sharp on the post page and render reliably in email clients across every device size.
4
Upload to your Substack post
Drop the compressed file into the Substack editor through the inline image button. Add a caption and alt text for accessibility and image SEO, then publish or schedule the post. The same compressed file will be used for both the web post and the email version sent to subscribers.

Real-world examples

Common situations where this approach makes a real difference:

Weekly photography newsletter with five inline photos

A photography focused Substack publishes weekly issues with five to seven inline photos. Original RAW exports come out at 12MB each. After resizing to 1456 pixels and compressing at 82 percent quality, each image lands at 280KB. The web post loads in 1.4 seconds on mobile, the email delivers reliably across Gmail, Outlook, and Apple Mail, and subscribers comment on how snappy the reading experience feels compared to other photography newsletters they receive.

Long form essay with embedded historical images

A long form essay Substack publishes 5000 word pieces with eight to ten embedded archival photographs. Original scan files average 6MB. After running each through the FixTools Image Compressor at 84 percent quality at 1456 pixel width, each archival photo lands at 320KB with preserved detail in the textures that make historical photographs visually interesting. The email message arrives well under the 5MB threshold that some corporate spam filters use as a soft flag.

Travel writing Substack with photo heavy posts

A travel writing Substack publishes 15 to 20 inline travel photos per issue, with each post functioning more like a visual essay than a written piece. After establishing a pre-compression workflow at 1456 pixels and 82 percent quality, average image weight drops from 5MB to 290KB. The full post email delivers in under 4MB total, the web post loads fast enough to keep mobile readers engaged, and the publication retains photo quality that does justice to the destinations being covered.

Business analysis Substack with chart and graph images

A business analysis Substack embeds two to four charts and screenshots per post. Original PNG exports from Excel and Tableau average 800KB to 1.4MB each. After converting to JPEG at 86 percent quality at 1456 pixel width to preserve text legibility in chart labels, each chart lands at 180KB. Charts remain perfectly readable, the email arrives instantly even on slow mobile connections, and the publication reads as polished and professional across every device subscribers use.

Pro tips

Get better results with these expert suggestions:

Resize to 1456 pixels wide for Substack post body

The Substack post body displays at 1456 pixels wide on desktop, with CSS scaling handling mobile rendering. Resizing your image to exactly that width before compression eliminates any client side scaling step and produces the sharpest possible display on the post page. Any image wider than 1456 pixels is wasted bytes that slow down both the web post and the email version sent to subscribers.

Use quality 80 to 84 percent for the web and email balance

For typical editorial photography at the Substack post width, JPEG quality between 80 and 84 percent produces files between 200 and 400KB with visual quality that looks sharp on the post page and renders reliably in email clients. That range is the sweet spot for the dual web and email rendering context that every Substack post lives in. Going below 75 percent quality can introduce visible artifacts in the email version that subscribers notice.

Push quality to 86 percent for charts and graphs with text

Charts, graphs, screenshots, and any image with embedded text labels are more sensitive to JPEG compression than photographs. Use quality 86 percent at 1456 pixel width for these specific image types to preserve text legibility in labels, legends, and axis values. The slightly larger file size of around 300 to 450KB is still well within reasonable email delivery limits and worth the readability gain for analytical content where the chart is the point.

Keep total post image weight under 4MB for reliable email delivery

Some corporate spam filters flag email messages above 5MB and some older email clients struggle to render messages above 10MB at all. Keeping the total weight of all inline images in a single Substack post under 4MB ensures reliable delivery to every subscriber including those on corporate email systems with strict size policies. Pre-compressing each image to 200 to 400KB makes hitting this ceiling natural even for posts with eight to ten inline photos.

FAQ

Frequently asked questions

Resize images to 1456 pixels wide before upload, which matches the Substack post body width on desktop and produces clean rendering on mobile through CSS scaling. Compress at JPEG quality 80 to 84 percent, which produces files in the 200 to 400KB range that look sharp on the post page and render reliably in email clients. Going wider than 1456 pixels wastes bytes that slow both the web post and the email version. Going narrower than the post body width causes the image to appear smaller than intended on desktop and can disrupt the visual rhythm of a long form post.

Substack serves images through its CDN with WebP variants for modern browsers on the web post version, but the email version sent to subscribers typically uses the original JPEG or PNG source you uploaded. Most email clients do not perform responsive variant selection and aggressively cache the first version they render. Pre-compressing each image to under 400KB at the Substack post width gives both the web and email rendering contexts a clean base to work from and ensures consistent visual quality across every device and reading context subscribers might use.

Slow Substack email loading on mobile is almost always caused by oversized images in the post. A single 6MB inline photo in a post with three other images can push total message size above 20MB, which some mobile email clients struggle to render quickly and some corporate gateways flag as suspicious. Pre-compressing each inline image to 200 to 400KB keeps total message size manageable, typically under 4MB even for image heavy posts, and produces a snappy reading experience across every email client and device size subscribers use to read your newsletter.

For charts, graphs, screenshots, and any image with embedded text labels, push JPEG quality to 86 percent at 1456 pixel width. This preserves text legibility in chart labels, legends, and axis values that lower quality settings can blur enough to undermine the analytical point of the image. The resulting files typically land at 300 to 450KB, which is still well within reasonable email delivery limits. For straight photography without embedded text, the standard 80 to 84 percent quality range produces better file size with no visible quality compromise.

The image they see depends on their reading context. On the public Substack web post, readers see the WebP variant served by the Substack CDN, which is typically smaller and slightly sharper than the email version. In the email, subscribers see the original JPEG or PNG source you uploaded, rendered by their email client which may apply its own image handling such as caching or proxy fetching. Pre-compressing at quality 80 to 84 percent at 1456 pixel width produces consistent visual quality across both contexts that looks polished regardless of how the subscriber chooses to read the post.

No. The compression runs locally in your browser using JavaScript and the HTML5 Canvas API. Your image is decoded in browser memory, re-encoded at the quality level you set, and made available to download as a new file, all without any network request leaving your machine. That privacy guarantee matters for subscriber exclusive photography, embargoed reporting, original journalism, and any content that should not pass through external services before reaching Substack. Even on a monitored network, your file does not appear in any captured traffic from the FixTools session.