Logo

MonoCalc

/

Social Media Image Size Guide

Social Media
No spec rows ship with this tool
A dimension is a fact about someone else’s product, so a row here is only allowed to exist with a link to the platform’s own documentation and the date that page was read. No documentation host was reachable from the environment this tool was built in, so rather than fill the table from memory it ships empty. The fit and crop calculator below needs no table at all. Add rows yourself as you check each platform’s published spec — they stay in this browser.

Fit and crop calculator

Your image

Aspect ratio 4:3

Only the width and height are read. The file never leaves your device — there is no upload. Limit 30 MB.

Target size

The table has no rows yet — add one below, or type a size here.

Set the target to a plain ratio, keeping its width:

Aspect ratio 16:9

Different shape
The source is 4:3 and the target is 16:9. Something has to give: fit adds empty bars, fill discards 25.0% of the source.
Under fit: pillarboxed
The whole source lands as 1,440 × 1,080, leaving 240 px empty to the left and 240 px to the right.
Under fill: cropped top and bottom
A centred crop keeps a 4,032 × 2,268 band of the source and discards 378 px from the top and the same from the bottom — 25.0% of the image.

Target — 1,920 × 1,080 · 16:9

Your image — 4,032 × 3,024 · 4:3

Hatched — Cut 378 px from the top (discarded by the crop)

Hatched — Cut 378 px from the bottom (discarded by the crop)

The source, scaled to cover a 1,920 × 1,080 16:9 target, overhangs it. The shaded bands are the 25.0% a centred crop discards.

Scaled to1,920 × 1,440 px
Scale factor0.476×
Kept from the source4,032 × 2,268 px
Area discarded25.0%

Published size reference

No rows yet. Open a platform's own documentation, read the figure there, and add it with its link and date.

About This Tool

Social Media Image Size Guide — published sizes and what a crop costs

Two different questions hide inside “what size should this image be?”. The first is a matter of record: what dimensions does a platform actually publish for a given placement? The second is geometry: given the image you already have, what happens to it when it meets that frame? This tool keeps them apart. The reference table answers the first and cites a source for every figure. The fit and crop calculator answers the second, and needs no table at all.

A display size is not a hard limit

These two constraints get flattened into one number constantly, and the difference decides whether your upload fails or quietly changes. A hard limit is a rule the upload is rejected for breaking: a minimum width, a maximum file size in bytes, a format that is not accepted. You find out immediately. A display size is the frame the image is shown in after it has been accepted. Hand over something a different shape and the platform scales and crops it to fit on its own, without telling you which pixels it dropped — which is how a portrait photo ends up as a wide banner with the top of someone’s head missing. Each row in the table records which kind of constraint it is, taken from the same page as the numbers.

Aspect ratio matters more than absolute pixels

Resolution is negotiable; shape is not. An image at 1280×720 and one at 1920×1080 are the same shape — both reduce to 16:9 — so moving between them only resamples the picture. Every pixel that was in the frame is still in the frame. Change the ratio, though, and something has to be thrown away or something has to be added, because there is no way to map a tall rectangle onto a wide one while keeping all of it and filling all of it. That is why the calculator reduces both sizes to their ratio first, with a greatest-common-divisor reduction, and falls back to a decimal form like 1.91:1 when the whole-number terms get too large to recognise.

Fit and fill are the two honest answers

When the shapes disagree, you have exactly two options and both cost something. Under fit, the image is scaled until the whole of it sits inside the target. Nothing is lost, but the target is not filled: the leftover shows as empty bars above and below (letterboxing) or at the sides (pillarboxing). Under fill, the image is scaled until it covers the target completely and the overhang is cut off. The frame is full, but pixels are gone — and because the crop is centred, what goes is whatever sat nearest the edges. The calculator reports the scaled size, the depth of each bar or each cut in pixels, and the share of the original area a fill discards, so “it gets cropped a bit” becomes a number you can decide against.

Why the diagram is the point

A percentage is hard to picture. The diagram draws both rectangles on a single shared scale around one centre, so the overhang is visible as an overhang: you can see the band that a crop removes, and its depth is written on it in pixels. Every shaded region is named in the legend in words as well, so nothing in it depends on being able to distinguish the shading.

Enlarging does not add detail

Upscaling invents pixels, it does not recover them
When the target is larger than your source on either axis, the extra pixels are interpolated from their neighbours. The file gets bigger and the picture gets softer — and whatever compression the platform applies afterwards is then working on that softness. Re-exporting from the original at the larger size, where you still have it, is the only thing that genuinely adds detail.

Why every row carries a link and a date

A dimension is a fact about someone else’s product, and platforms change published sizes, aspect ratios and file-size caps without notice and without a changelog. Aggregator pages repeat figures that were already wrong when they were copied. So a row is only allowed to exist here with the address of the page the figure was read on and the date it was read, and the table shows you both. Treat each one as a snapshot on its own date and nothing more: before you export something that matters, open the link and confirm the number still reads the same. None of this data is live, fetched or synced, and it is deliberately better for the table to be short than for it to be confident and wrong.

What this tool does not do

It never touches your image. There is no canvas drawing, no re-encoding and no modified file to download — it is arithmetic and an SVG diagram. If you point it at a local file, the only thing read is the width and height, purely so you do not have to type them; the file never leaves your device. Rotated JPEGs are decoded through the browser’s orientation-aware path so the numbers match what you see rather than how the bytes happen to be stored, and the tool says so when that path is not available.

Frequently Asked Questions

Is the Social Media Image Size Guide free?

Yes, Social Media Image Size Guide is totally free :)

Can I use the Social Media Image Size Guide offline?

Yes, you can install the webapp as PWA.

Is it safe to use Social Media Image Size Guide?

Yes, any data related to Social Media Image Size Guide only stored in your browser (if storage required). You can simply clear browser cache to clear all the stored data. We do not store any data on server.

How does this size guide work?

It does two separate things. The fit/crop calculator takes the width and height of an image you already have, compares them against a target size you choose or type, and works out exactly what happens to your frame: the two aspect ratios reduced, whether anything has to be enlarged, how much empty bar a fit leaves, and how many pixels and what share of the area a centred fill discards. A scaled diagram draws both rectangles on one scale so you can see the overhang rather than read it. The second part is a reference table of published platform sizes, each row carrying the address of the page the figure was read on and the date it was read. Everything runs in your browser and nothing is uploaded.

Why does the reference table start empty?

Because a dimension is a fact about somebody else's product, and this tool will not assert one it cannot cite. Every row is required to carry a link to the platform's own help or developer documentation and the date that page was read. When this tool was built, the environment had no network route to any of those documentation hosts, so not a single figure could be read at its source, and the rule is that no row ships rather than a table assembled from memory. A missing row costs you ten seconds; a confidently wrong number costs you a re-export and a re-upload, and nothing on the page would have warned you. You can add rows yourself as you check each platform's published spec, and they are kept in your browser.

What is the difference between a display size and a hard limit?

A hard limit is a constraint the upload is rejected for breaking — a minimum width, a maximum file size, a format that is not accepted. A display size is a size the image is shown at after being accepted: upload something a different shape and the platform scales or crops it to that frame on its own, without telling you which pixels it dropped. The two are not interchangeable, and a table that blurs them will have you rejecting a usable file or shipping one that gets silently cropped through the middle of a face. Each row records which kind of constraint it is in its notes, taken from the same source as the numbers.

Why does the tool warn about enlarging an image?

Because scaling up cannot recover detail that was never captured. When the target is bigger than the source on either axis, the extra pixels are interpolated from the ones around them: the file gets larger and the picture gets softer, and any compression the platform applies afterwards works on that softness. The calculator flags this whenever it happens so the number is not mistaken for a free upgrade. Re-exporting from the original at the larger size, where you still have it, is the only thing that genuinely adds detail.

Does this tool resize or crop my actual image file?

No. It is arithmetic and a diagram, and it never touches image pixels — there is no canvas drawing, no re-encoding and no download of a modified file. If you point it at a local file, the only thing read is the width and height, so you do not have to type them; the file itself never leaves your device and nothing else about it is inspected. Rotated JPEGs are handled through the browser's orientation-aware decoder so the numbers match what you actually see rather than how the file happens to be stored.

How far should I trust the dates on these rows?

Treat every row as a snapshot taken on its own verifiedOn date and nothing more. Platforms change published dimensions, aspect ratios and file-size caps without notice and without a changelog, so a row that was right when it was recorded can be wrong months later with nothing on this page changing. That is exactly why each row shows its own date and a link to the page it came from: before you export something that matters, open the link and confirm the figure still reads the same. This data is never live or synced.