Is Your Podcast Artwork Ready?

Apple's own show-cover template guidance calls for artwork at 3000 x 3000 pixels, with 1400 x 1400 pixels as the minimum accepted when artwork is submitted through an RSS feed. The image must be JPEG or PNG, cannot contain transparency, and must not include an alpha channel -- Apple explicitly rejects artwork built with a transparent background, which is a common mistake when a cover is exported straight out of a design template with layers left ungrouped. The artwork also has to be perfectly square: Apple Podcasts, like every major directory, displays cover art at a fixed 1:1 ratio, and anything else gets stretched, cropped, or rejected outright depending on where it is submitted. Apple applies the same square, RGB, no-transparency rules to optional episode-level artwork, so it is worth locking in one consistent export process rather than re-deriving the rules each time.

Spotify's published cover art requirements are similar but not identical. Spotify accepts images between 640 and 10,000 pixels on each side, also at a strict 1:1 aspect ratio, but recommends designing at 3000 x 3000 for parity with Apple's preferred size. Spotify asks for lossless encoding -- TIFF, PNG, or JPG saved without additional lossy compression -- and specifies an sRGB color space at 24 bits per pixel, explicitly rejecting embedded color profiles and orientation metadata. It also warns against upscaling a smaller image to hit the size requirement, since upscaled artwork looks visibly soft next to shows designed natively at full resolution. Since Spotify's floor of 640 px is far below Apple's 1400 px minimum, designing to Apple's stricter dimension and Spotify's color-space rules at once clears both platforms with one exported file.

Cover art is one of the biggest click-through drivers in podcast discovery, because most directories display it at thumbnail size -- often under 100 pixels square -- inside a scrolling list of dozens of competing shows. That constraint matters more than it looks: artwork that reads as sharp and legible at full size can turn into an illegible smear of texture and tiny type once it is shrunk down to a search-results thumbnail. Text-heavy covers are the most common casualty, since a host's name or show title set in a thin or decorative typeface reads fine at 3000 pixels but disappears completely at 60. Anyone testing new artwork should check it at the smallest size a directory actually displays, not just at full resolution on a large monitor.

The rejection reasons that show up most often are dimension failures (artwork below 1400 x 1400, or not square), file format problems (GIF, WebP, BMP, and SVG are not accepted by Apple or Spotify even though they are common web formats), and color space mismatches. That last one usually happens when artwork is exported from a print-oriented design tool that defaults to CMYK; the file opens and looks normal in that tool's own preview, but renders with shifted, muddy colors -- or fails outright -- once a podcast host or directory expects standard RGB. Oversized files are a subtler failure: nothing technically rejects a large PNG, but slow-loading artwork delays how quickly a feed's episodes and search results appear inside a podcast app.

The safest workflow is to design once at 3000 x 3000 pixels in RGB, then export two versions: a PNG master kept for archival purposes and a compressed JPEG at roughly 80-90% quality for actual submission, which comfortably satisfies Apple's dimension range and keeps the file small enough to load quickly across every directory. Re-check artwork any time a show gets rebranded or a host changes, since directories cache old covers inconsistently and a stale image can linger in one app's search results long after it has been replaced everywhere else. Running a quick check against the current requirements before every artwork update catches the handful of issues -- the wrong aspect ratio, leftover transparency, an accidentally re-exported CMYK file -- that are otherwise easy to miss until a directory quietly rejects the update.