Podcast cover art size, and the one rule nobody mentions

The specification, exactly

Apple's creator documentation gives 3000 x 3000 pixels as the standard Show Cover size. When submitting through an RSS feed, artwork is accepted anywhere from 1400 x 1400 to 3000 x 3000 pixels, and Apple states that the largest size is preferred. The shape is strictly 1:1. Accepted formats are PNG and JPG.

The requirement people miss is the last one: Show Covers cannot contain transparency and should not contain an alpha channel. This is not about how the image looks. A PNG can be fully opaque to the eye and still carry an alpha channel in its header, and that alone is enough to fail validation on some hosts.

Why the alpha channel catches so many people

Design tools export PNG with an alpha channel by default, because that is the format's main advantage. If you build your cover in a tool that ever had a transparent background, even for a moment, the exported file may well carry that channel forward.

There are two clean fixes. Export as JPG, which has no alpha channel at all and cannot fail this check. Or export PNG through a tool that flattens onto an opaque background first. When in doubt, JPG at high quality is the safer choice for cover art, because the format itself makes the mistake impossible.

Spotify and the other directories

Spotify's public help pages talk about cover art in terms of practice rather than publishing a hard numeric specification, and most other directories pull the artwork from the same RSS feed Apple reads. In practice this means the Apple requirements are the binding ones: satisfy them and you satisfy essentially everything else.

That is why 3000 x 3000 has become the de facto industry deliverable. It is the top of Apple's accepted range, it downscales cleanly to every smaller display size, and it means you produce one file rather than a set.

The display size is the real design constraint

Here is the part that determines whether your cover works. That 3000-pixel file is almost never seen at 3000 pixels. In a podcast app on a phone, cover art in a list is displayed at roughly the size of an app icon. On a smart speaker display or a car screen it can be smaller still.

So the design brief is not "make a 3000 x 3000 image". It is "make an image that still communicates at about 60 pixels, then deliver it at 3000". Those are very different briefs, and the second one rules out most of what looks good in a design tool at full size.

What survives at icon size

Short titles. A show name of one or two words at very large type will read; a five-word name with a tagline underneath will collapse into grey mush. If your show has a long name, set the memorable part large and let the rest be small — accepting that the small part is decoration, not information.

High contrast between the type and whatever is behind it. Strong, flat colour rather than photographic texture. And a silhouette that is recognisable before any of the words are: a distinctive shape, a bold colour block, one face. That silhouette is what a listener actually uses to find your show in a list they have scrolled a hundred times.

Where the cover actually turns up

It is worth being concrete about the surfaces, because they pull in opposite directions. The show page — the screen a listener lands on when they follow a link or search for you by name — is the one place the artwork gets room. It is displayed large, often as the dominant element on the screen, and it is where an illustration with some detail in it can do real work.

Everywhere else it is small. In a subscription list, a browse shelf or a set of search results, the cover sits at roughly app-icon size beside the title. On the lock screen and in the now-playing bar of a phone it is smaller still: a square sharing the space with the episode title and the transport controls, or a thumbnail in a notification. On a car head unit or a smart speaker display it is sized to be read at arm's length or further, and the software may round its corners or lay a play indicator over it.

Two things follow. The surface where you win a listener who does not know you — the browse shelf, the search result — is one of the small ones, while the surface that finally gives your cover space is usually reached after they have already decided to look. Design for the first and treat the second as a bonus. And because several of these surfaces round the corners or place the artwork against a background you cannot predict, anything sitting in the extreme corners of the square is at risk of being trimmed or lost against what is behind it.

The checklist before you submit

Before the file goes anywhere near your host, walk through it. Square: the two dimensions must be identical, and 2999 x 3000 is not square. Size: between 1400 x 1400 and 3000 x 3000 for an RSS submission, with the largest preferred. Format: JPG or PNG, and nothing else, whatever your design tool offers as its default export.

No transparency: if you are exporting PNG, confirm the file is flattened onto an opaque background and carries no alpha channel. If you cannot confirm it, export JPG instead and the question disappears.

Text large enough for the smallest display: shrink the preview until the cover is about the size of an app icon and read the show name back. If you cannot, the answer is fewer words at a larger size, not a bolder typeface. Nothing bleeding to the very edge: keep the name, any face and any logo a comfortable margin inside the square, so that rounded corners and thin borders drawn by the app take only empty space.

One last check that appears on no specification: make sure the file you are uploading is the file you think it is. A folder of near-identical exports is how a show goes live with the version that still had a typo in the subtitle.

A practical export routine

Design at 3000 x 3000 so you have the resolution. Before you export, shrink the preview to about 5 % and look at it. If you cannot read the name, no listener will either — and no amount of resolution fixes that.

Export JPG at high quality for the feed. Keep the layered original so you can produce the 16:9 version for the YouTube edition of the same episode without rebuilding it from scratch.