Format
| Property | Value |
|---|---|
| Long-edge max | 512 pixels |
| Format | WebP (with JPEG fallback negotiated by Accept) |
| Aspect | Card-native (typically 5:7 portrait) |
| Color profile | sRGB |
Printing DTO as image_url (front) and, where applicable, image_url_back for double-faced cards. Field names are stable; the URL contents are not — see “URL stability” below.
What you can do
- Display them. Inline in your UI, in tooltips, in social embeds. No restrictions on how they’re rendered.
- Cache them. Store the bytes, set a long TTL, serve them through your own CDN. Recommended at any non-trivial scale.
- Resize them down. Generating smaller derivatives (thumbnails, list-row icons) is fine.
What you can’t do
- Hotlink at scale. The URLs we return today resolve to a Cloudflare-fronted bucket. We make no commitment that any particular image URL will be reachable for any particular duration. A high-traffic public site that hotlinks our URLs will see broken images the day we rotate the bucket.
- Resize up. Don’t upscale a 512px source to 4K and present it as full-resolution art. The base asset isn’t there; you’ll just get blurry pixels.
- Republish as a dataset. Bulk-downloading every image and posting them as a torrent or dataset is one of the things that ends a developer account. See Abuse policy.
URL stability
Image URLs follow a deterministic shape today, but we treat the URLs themselves as implementation details:- The
image_urlfield will be present and non-nullon every printing. - The image at the URL will match the printing it’s returned with.
- Migrating to a new URL scheme will be announced in the changelog at least 30 days in advance.
- The exact URL format remaining
images.elestrals.com/.... - The same physical file being served forever from the same URL.
- Bandwidth or availability of these URLs for direct hotlinking.