X (Twitter) Image Size Guide

X/Twitter image size specifications for 2026

X does not publish a formal image specification page the way some other platforms do, so most of what circulates online is derived from community testing and inspection of served assets. The numbers below reflect observed behaviour as of 2026. Where the official position is silent, this guide says so rather than guessing.

How X displays a single image in the feed

When you attach one image to a tweet, X shows it inline in the timeline as a horizontal strip. The strip is roughly 16:9, but it does not show the full image — it crops to approximately the centre third of the image height. That cropped strip is what everyone sees while scrolling. When someone taps the image, it expands to the full frame. This two-stage behaviour is the root cause of most “my face got cut off” complaints.

The practical implication: if your image contains text, a face, or any element you want visible without a tap, that element needs to sit in the centre 40–50 % of the image height. A 1200 × 675 px image has its horizontal crop centred around the vertical midpoint, leaving roughly the top 200 px and the bottom 200 px out of frame in the collapsed view. If your subject fills the full height of the frame, assume it will be halved in the timeline.

Multi-image tweets follow slightly different crop rules. A two-image layout places both images side-by-side, each cropped tighter than a single image. Three or four images are arranged in a grid where the preview crops are tighter still. If your images are designed to communicate something specific — a comparison, a sequence — check how they render at the grid crop, not just the single-image crop. The only way to verify this without guessing is to post a test tweet from a throwaway account or use a preview tool.

Twitter Cards: summary_large_image versus summary

Twitter Cards are the rich link previews that appear when you tweet a URL. The most common type for editorial content is summary_large_image, which uses an og:image at 1200 × 628 px (approximately 1.91:1). The card takes up significant width in the feed and shows the image above the site name and headline. For a blog post or article, this is the format that gets shared millions of times — every time someone tweets your URL, that og:image appears.

The basic summary card is the smaller variant: a 144 × 144 px square thumbnail placed to the left of the title and description. X generates this thumbnail from the same og:image source by centre-cropping to a square. This means your 1200 × 628 px og:image must contain a recognisable subject near the centre that survives being cropped to roughly 628 × 628 px and then downsampled to 144 px. A wide landscape photograph with the interesting part at the edges will produce a useless thumbnail. Whether your site returns a summary card or a summary_large_image card depends on the twitter:card meta tag you specify in the page's HTML head. If that tag is absent, X falls back to summary by default.

Card images are cached by X's Card Validator and CDN. If you update your og:image without changing the URL, the old image may continue appearing in tweets for hours or longer. X provides a Card Validator tool that forces a re-fetch. After updating an og:image, run the URL through the Card Validator before posting to confirm the new image is being served. This is a frequent source of confusion when brands update campaign artwork and then wonder why the old image keeps showing up in shares.

Profile picture and header image: separate rules for each

The profile picture on X is displayed as a circle, cropped from a square source. The recommended upload size is 400 × 400 px, though X accepts images as small as 200 × 200 px. At smaller sizes the circle looks noticeably soft on high-density screens, so 400 px is the practical minimum for a clean result. The subject — face, logo, icon — should be centred and should not extend into the corner areas, which the circular mask clips off. A common mistake is designing something with a hard geometric shape that extends to the edges; the circle crop turns those corners into awkward truncated arcs.

The header image (the banner behind the profile picture) is 1500 × 500 px at a 3:1 ratio. This is where the display difference between mobile and desktop matters most. On desktop, the full 1500 × 500 px banner is visible (though the profile picture overlaps the lower left). On mobile, the banner is cropped to a taller aspect ratio — roughly 3:2 on most current devices — which clips the top and bottom. The precise crop varies by device screen size and is not officially documented. Keeping critical design elements within the central 1500 × 360 px band is a conservative approach that tends to survive both desktop and mobile rendering without clipping.

JPEG, PNG, and WebP: what X actually does with each format

X accepts JPEG, PNG, GIF, and WebP. For photographs and complex images, JPEG is the sensible choice: it compresses efficiently and X will recompress it on ingest anyway. For images with flat colours, graphic text, or hard edges, PNG tends to survive X's processing with fewer artefacts than JPEG because the source has no lossy compression artefacts for X's recompression to amplify.

PNG files with transparency are handled inconsistently. X fills transparent areas with a solid colour — typically white in light-mode contexts — but the exact fill behaviour depends on the client and is not formally specified. If your PNG logo or graphic has a transparent background and you want it to look right across all X clients, do not rely on transparency. Set the background colour yourself before uploading, whether that is white, black, or a colour that complements your design. This is not specific to X: most social platforms do something similar, and the fill colour is often client-dependent.

WebP is accepted by X's upload endpoint and is served back in WebP where the viewing browser supports it. From an upload quality perspective, WebP at equivalent file size typically preserves more detail than JPEG, particularly around text and sharp edges. Whether the practical difference is visible at X's display sizes is debatable, but WebP is a valid choice if you are already working in that format.

The real reason your image looks blurry: compression order matters

The question “why does my image look blurry on X?” comes up constantly, and the answer is almost always one of two things: the image was uploaded at a very large size and X resampled it down, or it was saved at high JPEG quality before upload and X's own compression created artefacts on top of that large file.

X resizes and recompresses images at ingest. The precise quality setting it targets is not published, but inspection of served images suggests something in the 75–85 % JPEG range for the web delivery copy. When you upload a 4000 × 2250 px image and X scales it down to the display target, it applies bilinear or bicubic resampling followed by JPEG compression. Fine text, thin lines, and high-contrast edges all suffer most from this two-step process. The solution is to do the resampling yourself first: resize to 1200 × 675 px, sharpen lightly if the content needs it, then save as JPEG at around 80–85 % quality before uploading. You control the resampling step rather than delegating it to X's ingest pipeline. The resulting upload is smaller and X has less work to do, which typically produces a cleaner output image.

A five-step pre-upload check for X images

Before posting any image to X, take two minutes to run through the following five checks. First, confirm the pixel dimensions match the placement you are targeting: 1200 × 675 px for a feed image, 1200 × 628 px for an og:image card, 400 × 400 px for a profile picture. Use the dimensions checker at the top of this page to read the exact size of your file without guessing. Second, check that the main subject sits within the centre 60 % of the image height, because the timeline crops the top and bottom of a 16:9 image in the collapsed feed view. If a face or headline is near the edge, it will be out of frame until someone taps. Third, if your image contains text, verify that the text is legible at half the full-size render: X displays the timeline at varying widths depending on screen size, and small type that looks fine at full resolution may be unreadable in a narrow feed column. Fourth, confirm the file size is under 5 MB; in practice a properly sized JPEG should be under 500 KB, so anything near the limit suggests you are working from an incorrectly formatted source. Fifth, if you are posting a URL rather than an attached image, run the target URL through X's Card Validator to confirm the og:image is being fetched correctly and is not serving a cached old version. These five steps catch the errors that cause about 90 % of “why does my X image look wrong” questions before the post goes live.

The image dimensions checker on this site reads pixel width, height, aspect ratio and file size from any JPEG, PNG or WebP file without uploading anything. Drop your prepared image there to confirm the dimensions before posting. For images you have downloaded from X to check whether resampling occurred, the same tool shows the exact pixel count of the served copy. If you are working with images that carry metadata — GPS coordinates, camera model, timestamps — the strip metadata tool removes all of it client-side before you post. And if your workflow involves images shared from an iPhone, the iPhone photo metadata guide explains which tags the Camera app embeds and which ones X is likely to strip on its own.