The Definitive Pre-Publish Image Checklist

Why Rushing Images Live Costs You More Than You Think

You spent forty minutes tweaking the color grade on a hero shot. You picked the perfect crop. You even ran it by a colleague. Then you hit publish — and six weeks later a site audit reveals the image is 4.2 MB, named IMG_20240918_092231.jpg, has no alt text, and is sized 3840 pixels wide for a 800px column. Every page load is dragging that file across the wire in full resolution.

This isn't about being precious. Every un-optimized image is a quiet tax on your site speed, your SEO, and your accessibility compliance. The fix isn't a new plugin or a better workflow tool — it's a checklist you actually run through before anything goes live. Here it is, broken into five stages you can move through in under ten minutes per image.

Stage 1: Compression — Get the File Size Under Control First

  • Set a file-size ceiling before you start. For full-width editorial images, 150–250 KB is a reasonable upper limit. Thumbnail or sidebar images should land under 80 KB. Anything above these thresholds needs another compression pass.
  • Choose the right format for the job. Photographs belong in WebP or AVIF (not JPEG in 2024). Logos, icons, and illustrations with flat color? SVG or PNG-8. Screenshots with fine text? PNG-24 or WebP lossless. Using the wrong format for the content type throws away free gains.
  • Run lossy compression, then check for artifacts. Tools like Squoosh, ImageOptim, or the Cloudflare Image Resizing API let you dial quality down incrementally. Start at quality 82 for WebP and zoom in on edge detail — fabric texture, hair strands, fine type. If those look soft or blocky, bring quality up to 85. Don't guess; zoom in at 100%.
  • Strip embedded thumbnails. JPEG files often carry a full-resolution embedded preview thumbnail that adds 20–60 KB for no reason. ExifTool's -ThumbnailImage= flag removes it cleanly.
  • Run a second-pass lossless optimizer. After lossy compression, pass the file through a lossless optimizer (Oxipng for PNG, MozJPEG's -optimize pass, or WebP's -pass 6). This typically removes another 3–8% without any quality loss — free savings you'd otherwise leave on the table.

Stage 2: Sizing — Match Pixels to Purpose

  • Find the actual rendered width before you export. Open browser dev tools, inspect the image element, and read the computed width at the largest breakpoint you support. Exporting a 1600px image for a column that maxes out at 720px doubles file size for zero visual benefit.
  • Export at 2× for high-DPI, not just at 1×. For images that sit on retina screens (which is most screens now), export at 2× the rendered width but compress more aggressively. A 1440px WebP at quality 75 often looks sharper on a retina display than a 720px image at quality 90, and the file size stays comparable.
  • Generate responsive variants if your CMS doesn't handle it automatically. At minimum: one mobile variant (≤ 600px wide), one tablet variant (≤ 1024px), one desktop variant. If you're manually generating srcset images, name them consistently: hero-blog-600w.webp, hero-blog-1024w.webp, hero-blog-1440w.webp.
  • Don't upscale. If your source image is 900px and your column needs 1200px, that's a source problem. Upscaled raster images look soft and add file weight without adding information. Fix the source or rethink the layout.
  • Check aspect ratio before export, not after. Confirm the crop matches the slot it's filling — a 16:9 slot fed a 4:3 image will either distort or get letterboxed by CSS, depending on how object-fit is set. Better to know this at export time.

Stage 3: Naming — Human-Readable, Keyword-Aware, Consistent

  • Ditch the camera default filename completely. DSC_4471.jpg tells search engines and screen readers exactly nothing. Every image that goes live should have a descriptive name.
  • Use hyphens, not underscores or spaces. Google's crawlers treat hyphens as word separators; underscores are treated as word joiners. red-leather-sofa-living-room.webp is three separate keyword signals. red_leather_sofa_living_room.webp reads as one long compound word.
  • Keep the filename under 70 characters and skip filler words. You don't need "image-of" or "photo-showing" in a filename. espresso-machine-stainless-countertop.webp is better than photo-of-an-espresso-machine-sitting-on-a-stainless-countertop.webp.
  • Match the filename to the primary keyword of the page, not just the image subject. If you're publishing a guide about cold brew ratios, cold-brew-coffee-ratio-guide.webp reinforces the page topic better than mason-jar-coffee.webp, even if both describe what's in the image.
  • Establish and stick to a naming convention for image variants. Agree on a suffix scheme (-thumb, -hero, -og for Open Graph) and enforce it across the team. Inconsistent naming creates CMS chaos within six months.

Stage 4: Alt Text — Not an Afterthought

  • Write alt text for the human who can't see the image. Describe what's actually there: the subject, context, and anything that makes the image meaningful in the surrounding content. "Coffee" is useless. "Overhead view of a French press mid-plunge beside a ceramic mug and a wooden spoon on a white marble surface" is useful.
  • Don't front-load keywords unnaturally. Alt text that reads like a keyword list triggers accessibility red flags and feels manipulative. The keyword can be present, but the primary job is description, not SEO stuffing.
  • Decorative images get empty alt text, not no alt text. An image used purely for visual decoration (a divider stripe, a background texture) should have alt="" explicitly set. Missing alt attributes are accessibility violations; empty alt attributes tell screen readers to skip the image intentionally.
  • Check length. Most screen readers truncate alt text around 125 characters. If your description runs longer, you probably need a longdesc or a visible caption instead.
  • Read it out loud. Seriously — read your alt text aloud in context, as if you're describing the image to someone on a phone. If it sounds awkward, stilted, or keyword-stuffed, rewrite it.

Stage 5: Metadata — The Invisible Layer That Still Matters

  • Strip personally identifiable EXIF data before publishing. GPS coordinates embedded by smartphones can reveal your home address or the exact location of a private shoot. ExifTool's -all= flag strips all EXIF. You can selectively preserve copyright fields after stripping.
  • Embed copyright and creator credit if you own the image. Fields like Copyright, Creator, Rights, and UsageTerms in IPTC/XMP metadata create a machine-readable paper trail. If your image is ever scraped or redistributed, this data can survive file renames.
  • Set a meaningful image title in the CMS media library. The "Title" field in WordPress, Webflow, or Contentful often pre-populates from the filename. Change it to a proper sentence-case description. This field surfaces in media library searches, which matters when your library hits 3,000 files.
  • Confirm the Open Graph image is sized correctly. If this image will serve as the social share thumbnail, it needs to be exactly 1200×630px. Check that your CMS is pointing to the right variant — not the original 4K file, not the 600px mobile crop.
  • Verify HEIC/HEIF source files were fully converted. Some CMSes silently accept HEIC uploads and re-serve them. HEIC has poor browser support outside Safari. Confirm the final delivered format in the browser network panel, not just the filename you uploaded.

The 60-Second Final Check

Before you close the tab, run this rapid sanity pass:

  1. Open the published page, open DevTools Network tab, filter by "Img," reload. Confirm the delivered file size matches your compressed target.
  2. Inspect the <img> element. Confirm alt is present and meaningful. Confirm width and height attributes are set (prevents layout shift).
  3. Paste the URL into Google's Rich Results Test or a social debugger (Twitter Card Validator, Meta Sharing Debugger) to confirm the OG image loads correctly.
  4. View the page on a phone over a throttled connection (DevTools → Network → "Slow 3G"). If the image is the last thing to load and the page jitters around it, you missed a layout shift fix or the file is still too heavy.

None of this takes long once it's habitual. The first few times through this checklist might feel slow. By the tenth image, it's muscle memory — and the payoff compounds quietly every day in faster pages, better rankings, and images that work for every visitor, regardless of how they're accessing your content.

Disclaimer: This article is for general informational and educational purposes only and does not constitute professional, financial, medical, or legal advice. Results from any tool are estimates based on the inputs provided. Always verify important details and consult a qualified professional before making decisions.