The Right Screenshot Size for X, LinkedIn, Slack, and Docs

A screenshot that looks perfect in your editor can still go wrong the moment you post it somewhere else. X crops the top and bottom off a tall image. LinkedIn shrinks a wide one down to a thumbnail nobody bothers to click on. Slack renders it at a size that makes small text unreadable until someone clicks to zoom in. None of this is a bug in the platform — it's what happens when an image's dimensions don't match how that platform actually displays images, and most people never check.

The fix isn't complicated, but it does mean treating "screenshot size" as a real decision instead of whatever your display happened to produce. Here's what each major platform actually wants, why, and how to set your canvas and export settings once so you're not manually resizing every image before you post it.

Why "just take the screenshot" isn't enough

Three separate things determine how an image ends up looking on someone else's screen, and conflating them is where most sizing problems start:

1. Aspect ratio — the shape of the image (16:9, 1:1, 4:5, etc.). This decides what gets cropped in a feed preview, not how sharp it looks.
2. Pixel dimensions — the actual width and height in pixels. This decides sharpness, especially on high-DPI phone and laptop screens.
3. File size — the size in megabytes. This decides whether a platform compresses your image further after you upload it, sometimes visibly.

A screenshot captured at your monitor's native resolution has a pixel count and aspect ratio determined entirely by your screen and your crop — not by where you're about to post it. That's fine for a quick internal Slack message. It's a problem the moment the image needs to look intentional somewhere with a fixed preview shape, like a social feed.

X (Twitter)

X displays a single landscape image at its best when it's 1200×675px (16:9) — that ratio fills the timeline preview on both desktop and mobile without cropping. A square 1200×1200 image also renders without cropping and works well in multi-image posts. Anything outside those ratios gets cropped to fit the preview box, which is how you end up with a screenshot missing its top bar or a code snippet's last line cut off.

Two practical limits worth knowing:

• Max file size is 5MB for JPG, PNG, or WebP.
• Images get re-compressed by X after upload regardless of what you send, so starting from a bloated, uncompressed PNG doesn't buy you anything — it just makes the upload slower.

For a UI screenshot or a code snippet you want to post uncropped, 16:9 at roughly 1200–1600px wide is the safe target.

LinkedIn

LinkedIn supports three shapes without cropping: 1200×627 (landscape, ~1.91:1), 1080×1080 (square), and 1080×1350 (portrait, 4:5). Landscape is the traditional choice for a "here's a screenshot of what we shipped" post, but square and portrait aren't cropped either — they just take up more vertical space in the mobile feed, which in practice tends to get more attention while scrolling.

LinkedIn recommends staying at or above 1080px wide regardless of shape. Below that, images start looking soft even before LinkedIn's own compression kicks in. For anything with readable text in it — a UI screenshot, a chart, a quote card — don't go under that floor.

Slack

Slack is the odd one out: there's no fixed preview shape to design around, because Slack doesn't crop images the way a social feed does. It renders whatever you upload as an inline preview, scaled to fit the channel width. That sounds forgiving, and mostly it is — but it creates a different failure mode. A screenshot captured at full 4K monitor resolution gets scaled down hard to fit a normal channel pane, and any small text in it becomes unreadable until someone clicks through. On desktop, Slack doesn't compress your upload; on mobile, compression is on by default unless it's turned off in settings, so the same image can look noticeably softer to a teammate checking Slack from their phone.

There's no ideal Slack dimension to hit, but there is a practical range: keep the image no wider than roughly 1200–1600px, and make sure any text you need someone to actually read is large enough to survive being shown at maybe half that width in the channel pane. If a detail is genuinely small, it's worth using a zoom callout or crop to isolate it rather than relying on someone to open the full image.

Docs, READMEs, and blog posts

Documentation platforms — a GitHub README, a Markdown-based docs site, a blog post — usually render body content in a column somewhere between 700 and 900px wide. An image embedded at 4000px wide isn't rendered at 4000px; it's scaled down to fit that column, which means all those extra pixels just add to the file size and load time without adding any visible sharpness.

The right move is the opposite of "capture at maximum resolution": export at roughly 1200–1600px wide, which is enough for a 2x-scaled export to still look sharp on a retina display when the browser displays it at 700–800px, without shipping a multi-megabyte image for no visual benefit. PNG is worth keeping for screenshots with UI text and hard edges — it compresses cleanly without introducing JPEG artifacts around small type. Photos or backgrounds inside a screenshot compress fine as WebP if file size matters more than exact pixel-for-pixel fidelity.

How to actually hit these numbers without resizing by hand

Doing this manually — crop, resize, re-export, check the file size, repeat — is exactly the kind of busywork a screenshot editor should remove. In Savvyshot, two separate controls cover it:

• Canvas aspect ratio, in the Canvas section of the sidebar, lets you pick a preset ratio (1:1, 4:3, 16:9, and others) or enter a custom one. The canvas reflows around your screenshot to match, so you're setting the shape before you ever touch export settings — this is what gets you to X's 16:9 or LinkedIn's 4:5 without manually cropping pixels.
• Export size, in the export dialog (Ctrl/Cmd+S), lets you pick a scale multiplier — 0.5×, 1×, 2× — or enter exact width and height. Exporting at 2× is the right call for anything going somewhere with retina displays (which, at this point, is basically everywhere); it's what keeps a 1200px-wide image looking sharp instead of soft.

Neither of these is a "post to X" button — there's no platform-specific export preset baked in, in Savvyshot or in most competing editors, and that's fine. The two settings together cover every case above: pick the aspect ratio that matches where the image is going, then pick a pixel size and export format (PNG, JPG, or WebP) that keeps it sharp without needlessly inflating the file size. Once you've got a combination that works for a given destination, saving it as a canvas profile means you're not re-deriving these numbers from scratch next time — pick the profile, export, done.

The mistakes that actually show up

A few patterns account for most of the sizing complaints people run into after posting:

• Exporting at 1× from a retina display and posting to X or LinkedIn. The image technically meets the pixel dimensions, but it was captured or scaled down from a smaller source and looks visibly soft compared to a 2×-exported version at the same final size.
• Posting a tall, narrow screenshot (a full scrolling capture, for example) to a platform that expects landscape. It gets cropped hard, usually losing exactly the part — a footer, a final step, a total at the bottom of a table — that made the screenshot worth posting.
• Treating Slack's flexibility as "any size is fine." It technically is, but a screenshot that's unreadable until someone clicks through defeats the point of sharing an image instead of just describing the bug in text.
• Assuming a bigger file is a safer file. Every platform above recompresses on upload. Sending an unnecessarily large PNG doesn't preserve more detail after that recompression — it just makes the upload slower and, on some platforms, more aggressively compressed on the way back down.

None of these require a different tool to fix — they mostly require deciding on the shape and pixel size before export instead of accepting whatever the raw capture happened to produce, then letting each platform mangle it from there.