Bluesky Image Specs: The Complete 2026 Guide

Bluesky crossed 40 million accounts in early 2026 and the image handling still has sharp edges that Twitter never had. A big part of that is the AT Protocol doing the work: blobs are uploaded to your PDS, resized by a Bluesky-operated image server (bsky.app/img), and served back via content-hashed URLs. The upshot is that your uploaded bytes are not what anyone sees. This guide covers what actually happens to an image between upload and render.

The limits you care about

Surface	Dimensions (rendered)	Upload max	Accepted formats
Post image (single)	up to 2000x2000 fit	1 MB after client compression	JPEG, PNG, WebP, GIF
Post image (4-up grid)	1000x1000 tile	1 MB each	JPEG, PNG, WebP, GIF
Profile avatar	1000x1000 square	1 MB	JPEG, PNG, WebP
Profile banner	3000x1000	1 MB	JPEG, PNG, WebP
Feed/list avatar	1000x1000	1 MB	JPEG, PNG, WebP
Link card thumbnail	1200x630 source, 1000x1000 rendered	1 MB	JPEG, PNG, WebP
Video poster frame	auto from first frame	n/a	derived

The 1 MB limit is the hard cap the bsky.app client enforces after its own compression pass. Third-party clients like Graysky and deck.blue can push larger blobs (up to 10 MB) but the image server will reject anything above 10 MB regardless.

What the bsky.app client does to your upload

This is the part most posts skip. When you attach an image in the official web or mobile client, before it ever hits your PDS, the client does this:

1. Decodes the image to a canvas.
2. If either dimension is above 2000 px, it scales the image down so the long edge is 2000 px.
3. Re-encodes to JPEG at quality 0.8, iterating down to 0.7 and 0.6 if needed to hit the 1 MB limit.
4. Strips EXIF including orientation. The client applies the rotation first, so photos land right-side-up.
5. Uploads the blob. The image server then generates thumbnail derivatives on demand.

If you upload a 3000x4000 iPhone photo, by the time it reaches the CDN it is a ~1500x2000 JPEG at quality 0.7-0.8. There is no way to opt out of this in the first-party client.

How the image server serves your image

Bluesky's image server exposes URL patterns like:

https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:.../bafkrei....jpeg
https://cdn.bsky.app/img/feed_fullsize/plain/did:plc:.../bafkrei....jpeg
https://cdn.bsky.app/img/avatar/plain/did:plc:.../bafkrei....jpeg

The variants are:

• avatar - 1000x1000, center-cropped to square
• avatar_thumbnail - 128x128, center-cropped
• banner - 3000x1000, center-cropped
• feed_thumbnail - 2000x2000 fit with 30% quality JPEG (yes, 30%)
• feed_fullsize - 2000x2000 fit at 75% quality JPEG
• feed_video_blob - used for video posters

The feed_thumbnail is what you see in the timeline before you tap. The heavy quality drop is why pixel-art and screenshots look smeared in the feed but fine when opened. There is no way to force the feed_fullsize as the default.

Practical recipes

For a photo post where the grid preview matters, upload a 2000x2000 fit JPEG at quality 90 and accept that the timeline preview will be the 30% quality derivative. Your audience only sees the clean version after tapping.

For screenshots and pixel art, upload as PNG. The image server will still generate the lossy JPEG derivative for the feed, but the "view image" link returns the original PNG if it is under the size cap. This is the only way to preserve sharp text in a post.

For banners, design to 3000x1000 but keep critical content inside the center 1500x800 region. The mobile app crops aggressively on small screens.

For avatars, design on a 1000x1000 canvas and check the 128x128 render. Any fine linework in a logo falls apart at thumbnail size.

Link cards and the 1200x630 question

The Open Graph thumbnail your site provides is fetched by Bluesky's Appview, run through the same compression pipeline, and cached as a 1000x1000 square. If your OG image is a 1200x630 banner with text at the edges, the edges get cropped off. Design link preview images with the center 1000x630 region carrying all the information.

Batch workflows

If you post a lot of photos and want to control what the bsky.app client is going to do to them, pre-process your images to 2000 px on the long edge at JPEG quality 85. That way the client's re-encode pass mostly just strips EXIF and passes through. You can run a whole folder through Konvrt's batch converter or the single-image converter in the browser.

For alt text, the AT Protocol stores it as a separate field on the blob reference, so it survives re-shares. Bluesky's accessibility check in 2026 warns if posts with images lack alt text, and flagged posts get deprioritized in the Discover feed.

Takeaway: design to 2000 px long edge, expect a 30%-quality JPEG preview in the timeline, and stop uploading 4K images that will just get crushed.