A visually good cover can fail because the exported file or the RSS artwork reference is wrong. Check the actual show-cover dimensions, format and opacity, then confirm that the feed points to the publicly accessible image you intended. Keep this technical check separate from whether two hosts are attractively composed.
Identify which artwork you are submitting
A show cover represents the podcast as a whole. Episode artwork may be a separate asset with its own placement and requirements. Confirm which field your hosting provider is updating, rather than uploading a new image to an unrelated episode slot and expecting the show artwork to change.
Apple’s Show Cover guidance currently prefers 3000 × 3000 pixels. For RSS submission it accepts square artwork from 1400 × 1400 through 3000 × 3000, in PNG or JPG, without transparency or an alpha channel. Use the current specification for the destination and preserve its safe-area guidance.
An image that looks opaque can still carry an alpha channel. In an external editor, set an intentional solid background and export an appropriate no-alpha delivery copy. Reopen it and inspect the file properties instead of relying on the checkered editor preview or a filename ending in .jpg.
Check the artwork address from the feed
Inspect the show-artwork reference through your podcast host’s preview or feed tools. Open the referenced URL independently and confirm it returns the image rather than a login page, expired sharing link or generic website. Compare the remote file with the approved local export.
Apple’s RSS requirements cover public accessibility and hosting behavior, including support for HTTP HEAD and byte-range requests. Ask the hosting provider to handle these technical requirements if you do not manage the server. Changing the artwork alone will not fix a password-protected feed or unsuitable media endpoint.
Fictional example: After Hours Lab
After Hours Lab is an invented two-host podcast. The hosts approve their separate faces and the title composition. An image treatment may have begun through Imagild Image Prompt, but a designer finishes the exact title and square show-cover export in an external application.
The producer records three separate checks: local file properties, public artwork URL and feed validation. The local cover is opaque and correctly sized, but the first feed link points to an account-only preview. The producer replaces that reference through the external podcast host, verifies the public image and reruns the host’s validation. This example describes a diagnostic path, not a claimed live acceptance result.
Review small-screen appearance after technical fixes
Once the correct file is reachable, inspect the title and focal subjects at small display sizes. Avoid putting essential wording at the outer edge where interface elements can obstruct it. Technical validity does not establish legibility, and legibility does not prove that the feed is valid.
Keep the editable layout, approved opaque file and hosted URL record together. When replacing the cover, confirm which version the feed references and allow for the destination’s normal refresh behavior. Do not create a duplicate show merely because an old cached image remains visible briefly.
Should I enlarge a tiny image to 3000 pixels?
Prefer an adequately detailed source. Numeric dimensions alone do not make a stretched low-resolution picture readable.
Will a transparent PNG work because the app has a background?
Do not rely on the app to supply it. Apple’s current show-cover requirement excludes transparency and alpha; export the intended solid background yourself.