The 1 MB blob limit
The AT Protocol enforces a hard 1,000,000 byte limit on image blobs. When creating a post with a link card, the client downloads your og:image, compresses it under this limit, and uploads it as a blob to the user’s PDS.
If the image can’t be squeezed below 1 MB, the card may render without an image, or post creation may fail entirely. The behavior depends on the client.
Recommended dimensions
1200 x 630 pixels works well. Bluesky’s web app crops card images to roughly 1.91:1, same as most platforms.
Cropping behavior
Bluesky center-crops images to fit the card. Content near the edges of tall or wide images gets cut off. Cropping behavior has also varied across Bluesky clients historically, with some cropping taller images more aggressively.
Keep key text and visuals in the center 80% of the image to survive cropping across all clients.
Supported formats
- JPEG: recommended, compresses efficiently within the 1 MB limit
- PNG: supported, but large PNGs often exceed 1 MB
- WebP: accepted by CardyB but may be converted to JPEG during blob upload
- AVIF: not supported
Since the client re-compresses the image before uploading, your original format matters less than the final compressed size. JPEG gives the most predictable results.
Image re-upload behavior
Bluesky doesn’t hotlink your og:image URL. The image is re-uploaded to AT Protocol blob storage at post creation time:
- Your image server only needs to be available at the moment of posting
- After posting, Bluesky serves the image from its own CDN
- The original
og:imageURL is not stored in the post record - Changing the image at the original URL has no effect on existing posts
This is fundamentally different from platforms that re-fetch your image URL on every view.
Image URL requirements
The og:image URL must be:
- An absolute URL (not relative)
- Accessible to CardyB without authentication
- Served with a
Content-Typeheader indicating an image (notContent-Disposition: attachment) - Not behind redirects that require cookies or JavaScript