---
title: "Podcast Cover Art API: Art for Every Episode"
description: "A podcast cover art API renders per-episode artwork from a title and number. Square sizing, the artwork limits that matter, and the cost per season."
url: "https://www.imejis.io/blogs/use-cases/podcast-cover-art-api"
published: "2026-09-28"
---

# Podcast Cover Art API: Art for Every Episode

A podcast cover art API renders per-episode artwork from the data you already have in your publishing workflow: episode number, title, guest name, season. One square design, one render per episode, no design tool in the loop.

Show artwork is a branding job you do once. Episode artwork is a production job you do every week forever, which is a completely different problem and the one worth automating.

## Episode art and show art are not the same thing

Worth separating, because mixing them up is where the work goes wrong.

**Show artwork** represents the podcast. It sits at the feed level, it's what appears in a directory listing, and it changes maybe once a rebrand. Design that properly, by hand, once.

**Episode artwork** sits on the individual item in the RSS feed. It's where "Ep. 147" and the guest's name belong, and it's different for every episode you'll ever publish. That's the render target.

|                   | Show artwork          | Episode artwork               |
| ----------------- | --------------------- | ----------------------------- |
| Sits on           | The feed              | Each item in the feed         |
| Changes           | Once a rebrand        | Every episode                 |
| Carries           | The show's identity   | Episode number, title, guest  |
| Worth generating? | No, design it by hand | Yes, that's the repeating job |

Plenty of shows skip episode art entirely and inherit the show image. Generating it is a small edge, and the reason to bother is that it shows up in the player while someone is deciding what to listen to.

## Square, and bigger than you think

Podcast artwork is square, and the sizing rules are set by the directories rather than by taste. Apple Podcasts asks for artwork between 1400 by 1400 and 3000 by 3000 pixels, in RGB, as JPEG or PNG. Their [artwork requirements](ref:podcasters.apple.com/support/896-artwork-requirements) are the ones everyone else effectively follows.

Design at 3000 by 3000. Two reasons:

- Every directory scales down from your file. Downscaling looks good; upscaling a 1400 file to fill a large player does not.
- A render caps at 4096 by 4096, so 3000 is comfortably inside the ceiling with nothing to work around.

Dimensions are fixed at design time, which for a format with one mandated shape is no constraint at all. Square is square.

## Titles are the variable that misbehaves

Episode numbers are short and predictable. Titles are neither.

"Cold open" and "What we got wrong about distributed consensus, with Dr. Amara Osei" are going into the same slot. Auto-resize handles that without a person checking each render:

```json
{
  "key": "episode_title",
  "type": "text",
  "dynamic": true,
  "properties": {
    "autoResize": true,
    "minFontSize": 48,
    "maxFontSize": 132,
    "textAlignment": "left",
    "lineHeight": 1.1
  }
}
```

Set the minimum where the title is still readable as a thumbnail, because that's the size most listeners actually see it at. A title that technically fits at 20pt on a 3000px canvas is invisible in a player. [Text on image](/blogs/tutorials/text-on-image-api) covers the resize behaviour in full.

## Rendering it from the publishing step

The call is one request per episode, and it fits wherever your episode metadata already lives:

```bash
curl -X POST 'https://render.imejis.io/v1/YOUR_DESIGN_ID' \
  -H 'dma-api-key: YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "number": { "text": "147" },
    "episode_title": { "text": "What we got wrong about consensus" },
    "guest": { "text": "Dr. Amara Osei" }
  }' \
  --output ep-147.png
```

Two ways to wire it. Render at publish time and upload the file with the episode, which is the simple one and what most shows want. Or render with hosted delivery, get a permanent URL back, and put that in the feed item. [Delivery modes](/blogs/tutorials/image-api-delivery-modes) covers the trade there; for a feed that gets fetched constantly by every podcast client in the world, uploading a static file is the safer call.

## What a podcast cover art API costs per season

One render per episode.

A weekly show is roughly 52 renders a year. That is not a typo, and it's the reason to be honest here: at that volume, 100 free renders a month, no card, covers you forever and this post has not sold you anything.

Where it turns into a real workflow is a network:

| Setup                                               | Renders a month | Plan          |
| --------------------------------------------------- | --------------- | ------------- |
| One weekly show, cover art only                     | ~4              | Free          |
| Twelve weekly shows, cover art only                 | ~48             | Free          |
| Twelve weekly shows, plus social and a 16:9 variant | ~144            | Basic, $14.99 |

As of September 2026, Basic is 1,000 renders a month. The [pricing page](/pricing) has the rest.

## What this doesn't do

No audiograms, no waveform animations, no video. Those are the other half of podcast promotion and they're animated, which is outside what a static image renderer does. We don't do animation at all, so we'd point you at Headliner or Wavve rather than pretend otherwise.

It also won't write the title or pick the pull quote. It takes the data you have and turns it into a picture, reliably, at whatever volume you publish.

## Getting started

Build one episode's card as a design at 3000 by 3000, mark the number, title and guest dynamic, and render your last ten episodes to see how real titles behave in the layout. The [text component](/components/text) page has the resize controls live, and the [API docs](/apis) have working calls to drop into a publishing script.