Media is where publishing gets specific. Text rules are simple — there is a character limit and you are either under it or you are not — but an image has a format, a size, a pixel dimension, sometimes an aspect ratio, and occasionally a colour-mode requirement, and every platform has its own opinion about all of them.

The result is that media failures are the most common reason a post goes out to three networks and not a fourth. They are also the most fixable, because the rejection almost always names a rule rather than a mystery.

This guide has two halves: the rules PostHub applies before anything leaves your machine, and the rules each platform applies when the file arrives.

The two layers, and why they disagree

Layer one is PostHub's own upload: the file picker in the composer, the drop zone in the media library, and the endpoint that stores the file. These rules exist to stop you from wasting a publish attempt on something that was never going to work.

Layer two is the destination platform. It has its own limits, they are frequently tighter than ours, and they are not negotiable — the platform wrote them, the platform enforces them, and the platform's error message is what you will see.

When the two layers disagree, layer one is a superset: PostHub will happily accept a file that a particular platform will later refuse. That is deliberate, because the same image can be valid for four of your five selected networks. But it means passing the upload is not the same as passing the publish.

PostHub's own rules

Images only. The composer's file picker accepts images, the media library's drop zone accepts images, and the upload endpoint validates the MIME type against JPG, PNG, WEBP and GIF. Video files are rejected at upload with a message naming the allowed formats. Platforms that require video cannot be published to from the composer today, and attempting it produces a media error on that platform while the others succeed.

Ten megabytes. The upload limit is 10 MB for every image, before any platform rule is applied. The composer checks the size as soon as you pick the file, so you find out before writing three hundred characters of caption rather than after pressing publish.

One image per post. The composer attaches a single image. Several platforms would accept four or more from the same post — X, Bluesky and Mastodon all allow multiple images — but the editor currently holds one. If a post needs a carousel, that is a per-platform concern rather than something this build produces.

Image type must be an image. The picker filters on image MIME types, and the endpoint re-checks. A renamed .jpg that is really a PDF or a HEIC file from a phone will pass the picker on some systems and fail the server's validation, which is a confusing place to be — if the upload is rejected, check what the file really is rather than what it is called.

The per-platform reference

What follows is every platform PostHub can publish to, with the media rules that matter. Sizes are the platform's own limits, not PostHub's.

X (Twitter) accepts up to four images and video up to about 512 MB, with images capped at 5 MB each. It is the most permissive of the image platforms on count and generous on video, which is why multi-image posts work well there. Anything with a URL in the caption also changes the API cost, but that is a billing rule rather than a media one.

Instagram takes one image or one video, and media is mandatory — a text-only post is rejected outright. Images are capped at 8 MB, video at 100 MB, and the account must be Professional (Business or Creator). Instagram also cares about aspect ratio more than the others: square, portrait and landscape are all fine, but an extreme aspect ratio will be cropped by the platform rather than rejected, which is worth previewing before you publish.

Facebook takes one image or video per post through this path, with a 10 MB image cap and a generous 1 GB video cap. Media is optional on Facebook, which is why the same post can succeed there and fail on Instagram when it has no image.

Threads mirrors Instagram: one image or video, media required, 8 MB images, 1 GB video, and a strict daily publishing cap that has nothing to do with file size.

LinkedIn takes one image or video and requires media for the post types PostHub publishes. Images are capped at 8 MB, video at 200 MB. LinkedIn also re-encodes aggressively, so a file that looks correct in preview can arrive slightly different — if your image has fine text, keep it large enough to survive that re-encode.

YouTube is video only, and media is mandatory. Images are not accepted at all. The file-size ceiling is enormous — well beyond anything the composer would produce — so the practical constraint is upload time and the daily quota rather than size.

TikTok is video only as well, with media mandatory and a 4 GB ceiling. The platform's own rules about aspect ratio and duration are stricter than any number here; vertical video is the expectation and anything else will look wrong even if it uploads successfully.

Vimeo is video only, media mandatory, 500 MB per upload on the free tier and a weekly bandwidth budget above that. The composer's 10 MB image rule is irrelevant here because Vimeo does not take images through this path at all.

Tumblr accepts one image or video per post, 10 MB images, 100 MB video. It is one of the more forgiving destinations, and the most common Tumblr failure is not media but an unverified email address on the account.

Mastodon accepts up to four images and video up to about 40 MB, with an 8 MB image cap. The effective limits, though, come from the instance you are posting to: a self-hosted instance may set lower ceilings than the public ones, and PostHub reports whatever that instance says.

Bluesky accepts up to four images and no video at all through this path, with an unusual image ceiling of roughly 976 KB. That number is the single most common Bluesky surprise: a photograph that is well under a megabyte on your disk can still be over the limit after a phone's camera pipeline, and a file that is fine for every other platform will be rejected here.

Dribbble accepts exactly one image and no video, media mandatory, 8 MB maximum — and then the rule that catches everybody: the image must be exactly 400x300 or exactly 800x600 pixels, in JPG, PNG or GIF. Not close, not proportional, not cropped by the platform: exact. The composer checks this while you pick the file and tells you your image's real dimensions, which is the only place in the product where a media rule is caught before upload rather than after publish.

Pinterest accepts one image, media mandatory, up to 20 MB, in JPG, PNG or GIF. Video Pins are not supported through this path because they require a cover image the composer does not collect — the integration advertises itself as images-only so that the UI and the adapter agree.

Telegram accepts one image or video, 10 MB images, 50 MB video. The bot must be a member of the target chat with permission to post, or Telegram rejects the message before media is even considered.

Google Business Profile accepts one image and no video through this path, capped at 10 MB. The post types available on a Business Profile are narrower than a social network's, so a post that works on Facebook may be refused here for format reasons rather than size.

The four rejections that account for most failures

After the platform rules, these are the actual errors people hit, roughly in order of frequency.

The file was too big for that platform, but not too big for PostHub. You uploaded a 9 MB photo, the composer accepted it because it is under 10 MB, and X refused it because X allows 5 MB per image. Both checks were correct; they were simply different checks, and the one that runs last is the one you see. The fix is compression rather than a smaller composition: re-export the image at a lower quality, or resize it to the dimensions you actually need to publish at. Most social images do not need to be larger than about 1600 pixels on the long edge.

The format is allowed by PostHub but not by that platform. WEBP is the classic case. PostHub accepts WEBP, Dribbble and Pinterest accept only JPG, PNG and GIF, and the result is a rejection that reads as if the file were corrupt. Export as JPG for those two and the same image publishes.

The dimension is wrong. Only Dribbble enforces exact dimensions today, and the composer warns you before upload, but a warning you have to read is a warning people skip. If Dribbble is in your platform selection and the image is 1200x800, it will never publish — resize to 800x600 first.

Media was required and there was none. Instagram, Threads, LinkedIn, Dribbble, Pinterest, YouTube, TikTok and Vimeo all refuse text-only posts. Selecting any of those without an image attached guarantees a failure on that platform. The rule of thumb: if the platform is visual-first, attach something.

A fifth, quieter failure is worth naming even though it is not really about media: the account was connected but the token had expired or been revoked, and the error you see is an authorisation error that arrives while you are thinking about images. If a media rejection does not sound like a media rejection — if it talks about permissions or tokens — read the message rather than the context.

Sizing and compression that survives every platform

If you want one set of habits that makes media failures rare rather than occasional, these five cover it.

Export as JPG for photographs, PNG only for images with transparency. Both are accepted by every image-capable platform in the product. WEBP and GIF are fine for some destinations and not others; using them as your default creates avoidable exceptions.

Keep the long edge around 1600 pixels. That is comfortably above what any of these platforms display and comfortably below most size limits. Phones now produce 4000-pixel images that add nothing to a social post while tripping every ceiling.

Aim for under 2 MB unless you know the destination allows more. Two megabytes passes PostHub, X, Instagram, Facebook, Threads, LinkedIn, Tumblr, Mastodon, Pinterest, Telegram, Google Business Profile and Dribbble after a resize. It fails only Bluesky's 976 KB rule, which needs its own export.

For Bluesky, make a dedicated small export. A copy of the image at lower quality, saved separately, is less painful in the moment than resizing the master while you are trying to publish. Keep it under about 900 KB and it will always go through.

Check Dribbble dimensions before you select the platform, not after. If you are cross-posting a shot, export the 800x600 version as part of your preparation rather than as a reaction to a rejection.

Text inside images

One rule nobody writes down but everybody learns: platforms re-encode images, and re-encoding softens fine text. A screenshot with 10 px type can arrive unreadable on LinkedIn after processing, while the same screenshot looks perfect in your preview.

If the image carries text — a quote card, a slide, a screenshot — keep the type large, keep the contrast high, and do not rely on hairline weights. The image that looks slightly too big on your screen is the one that survives the round trip.

This is also why a screen recording of a mobile app usually performs worse than a purpose-made card: the text was designed for a phone's pixel density, not for a social feed's compression.

Reading a media rejection

When a post fails on one platform with a media-related reason, the information you need is in the error text attached to that platform's result, not in the post's headline status.

A size rejection names a limit. A format rejection names a MIME type or an extension. A dimension rejection names the expected sizes. A "media required" rejection means the platform wanted something attached and found nothing. An authorisation rejection means the account, not the image, is the problem.

Work through them in that order and the second attempt usually succeeds. If the second attempt fails with a different message, you have eliminated one variable — which is progress, even though it does not feel like it.

The retry itself is safe: platforms that already received the post are skipped, so republishing after a media fix only touches the ones that refused.

What is not supported yet

Two absences are worth stating plainly so that you can plan around them rather than discover them mid-campaign.

Video uploads from the composer. The file picker takes images. Video platforms — YouTube, TikTok and Vimeo — cannot be published to from the composer because there is no video to attach, and the failure you will see on those platforms is a media error rather than a bug report. Keep them out of the composer's platform selection until video uploads land, or create those posts through a path that carries a video.

Carousels and multiple images per post. X, Bluesky and Mastodon all accept up to four images, but the composer holds one. A single strong image is the honest representation of what will actually be posted.

Both are product gaps rather than platform restrictions. The platforms would take the media today; the editor does not collect it yet.

Aspect ratio, orientation and cropping

Dimension limits are about how big the file is. Aspect ratio is about how it will look, and platforms are far more opinionated about the second than the first — they will usually accept an odd ratio and then quietly crop it.

Square (1:1) is safe almost everywhere: Instagram, Facebook, Threads, Tumblr, Pinterest, LinkedIn and Bluesky all display it without cropping in a feed. It is also the shape that wastes least when it is re-used across networks.

Portrait (4:5 or 9:16) performs well on Instagram and TikTok and is displayed tall on mobile, but gets letterboxed or cropped to square on some desktop feeds. If you publish portrait, preview it on a phone before you assume it looks right.

Landscape (16:9 or 3:2) is the natural shape for LinkedIn, YouTube thumbnails and X, and the one most likely to arrive cropped on Instagram — where it is usually reduced to a square with the sides trimmed.

Extreme ratios — panorama strips, very tall infographics, ultra-wide banners — are where cropping bites hardest. Instagram in particular will centre-crop rather than refuse, which means half your text can vanish without any error being reported at all. Nothing in this product will warn you, because the platform accepted the file.

The practical rule: design once for the most restrictive platform in your selection, and if that platform crops aggressively, export a second version rather than accepting the crop. A single square master with a portrait variant for Instagram covers nearly every cross-post you will ever write.

The other ratio trap is safe areas. Both Instagram and TikTok overlay interface elements — captions, buttons, progress bars — on the edges of the media. An image whose subject sits flush against the bottom edge can end up with a comment button on top of it. Keeping the important content inside the middle eighty per cent of the frame is a habit worth forming once.

Colour, transparency and other file quirks

Four properties that are invisible until a platform objects to them.

Transparency. A PNG with an alpha channel renders transparent areas as whatever the platform's background happens to be — usually white on light feeds and black on dark ones. That logo with a transparent background that looks correct on your desktop can arrive on a black tile with white fringes around the letters. If the artwork needs a specific background, flatten it onto that colour before exporting.

Colour space. Photographs edited in a wide-gamut or CMYK profile can shift noticeably when re-encoded by a platform that expects sRGB. If a photo looked warmer in your editor than it does on the destination, the colour space is the usual cause. Export in sRGB.

HEIC. Phones default to it, PostHub's upload validation does not accept it, and the failure message points at the format rather than at your camera settings. Convert to JPG before uploading. This is the single most common first-upload failure from a phone.

Animated GIF. GIF is accepted by the upload endpoint and by several platforms, but many platforms convert it to a static image or to a video on their side, and the result is not what you previewed. If the animation matters, verify it survived on the destination before you consider the post finished.

Screenshots. Technically perfect PNGs that are the wrong shape, the wrong size, and full of fine text. They are also the media most often attached in a hurry. Run them through the same export habit as everything else: crop to the ratio you want, scale to about 1600 pixels on the long edge, and check the text size after re-encoding.

One master, three exports

The habit that removes almost all of this from your week is preparing variants once, in a batch, rather than reacting to rejections one at a time.

The master. Your largest, highest-quality export — the source you would be happy to print. Keep it. Nothing you publish should be the master itself.

The standard export. JPG, sRGB, long edge around 1600 pixels, quality set so the file lands around 1–2 MB. This passes PostHub, X, Instagram, Facebook, Threads, LinkedIn, Tumblr, Mastodon, Pinterest, Telegram, Google Business Profile and Dribbble after a resize. Ten of your twelve image destinations, one file.

The Bluesky export. Same crop, lower quality, under about 900 KB. Save it under a name that makes the purpose obvious so you are not choosing between two files at publish time.

The Dribbble export. Exactly 800x600, JPG or PNG, under 8 MB. Only needed when Dribbble is in the selection, but needed exactly then and never before.

Three files, prepared in the same session as the caption, and the media layer of publishing stops being a source of surprises. It costs about ninety seconds per image and saves considerably more than that the first time you avoid a rejection.

Compressing without destroying the image

Compression is the fix for almost every size rejection, and done badly it creates a different problem: an image that passes the limit and looks like a watermark was applied.

Resize first, then compress. A 4000-pixel image re-encoded at high quality is both large and unnecessary. Scale it to the size it will be displayed at — around 1600 pixels on the long edge for most social images — and the file size falls by far more than any quality setting could achieve.

Then lower quality until the size is right, not until the image looks wrong. Most encoders look excellent down to about eighty per cent and start showing artefacts somewhere below sixty. Set the target as a file size, encode, look at it, and stop when it hits the target rather than guessing a percentage in advance.

Watch the flat areas. Gradients, skies and shadows are where compression artefacts appear first, usually as banding. If your image has a large smooth background, check it at full size after encoding.

Avoid double compression. A JPEG re-encoded from an already-compressed JPEG loses quality twice for no benefit. Export from the original or the master every time, never from a previous export.

Do not rely on the platform to fix it. Every platform re-encodes on arrival. Your file is being compressed once by you and once by them; the version you upload should already be clean enough that the second pass is invisible.

If you have no image tool at hand, any of the common online compressors will do this — but check the privacy policy before uploading client material, because you are handing the file to a third party in order to save a few hundred kilobytes. A local image editor avoids the question entirely.

What happens to your image after you pick it

Knowing the path explains a few behaviours that otherwise seem arbitrary.

You choose a file. The browser checks the type and the size and shows you the preview, which is the file exactly as it is on your disk — no processing, no re-encoding, no thumbnailing.

You publish. The file is sent from your machine to the server, validated again against the allowed MIME types and the 10 MB ceiling, and written to the server's media storage. From there it is served back through the application's own media route — there is no third-party CDN in the path by default, so the image's journey is your browser, your deployment, and then the platform.

When the publish runs, the platform's adapter reads the stored file and submits it to the platform's own upload endpoint, usually as multipart data alongside the caption. The platform then performs its own validation — its size limit, its format rules, its dimension rules — and either accepts the file or returns the refusal you eventually see.

After acceptance, the platform re-encodes. This is the step that changes your image: colour profiles are normalised, resolution may be reduced, and fine detail is softened. It happens whether or not you were expecting it, and it is the reason the post-publish reality on a platform can differ from your preview.

That path has two useful consequences. First, a rejection at the far end tells you nothing about whether your upload was fine — the file reached the platform, which means PostHub's own rules all passed. Second, because the stored file is the one you uploaded, fixing a rejection means replacing it: attach a corrected export and republish, rather than expecting the platform to reconsider the version it already declined.

Preparing video for the day video uploads land

Video cannot be attached in the composer yet, so this section is preparation rather than instruction — but the platforms' expectations are worth knowing while you are choosing what to shoot.

Vertical is the default for TikTok and Shorts-style destinations. 9:16, shot full-frame, with the same safe-area discipline as images: interface overlays will sit on the bottom and right edges.

YouTube expects 16:9 and treats almost anything else as a pillar-boxed afterthought.

Duration is a platform rule, not a technical one. Each destination has its own practical ceiling, and the shortest one in your selection should govern the cut.

File size matters less than bitrate. A large file at a sane bitrate usually uploads faster and looks better than a smaller one that was compressed hard — with the exception of Vimeo's tier limits, which are genuinely enforced.

Captions and thumbnails are separate concerns. Platforms that expect a title or a cover image will refuse a post without one, which is a content-structure failure rather than a media failure.

When video uploads do land, the media guide will grow a video section alongside this one. Until then, keeping video platforms out of the composer's selection is the correct workaround, and the failure you see if you forget is exactly the media-required error described above.

Naming, storing and finding your files

The rules above keep posts from failing. This section is about the month after that, when the same twelve images are circulating between a designer, a shared drive and three drafts.

Name files by what they are for, not by what they are. IMG_4821.jpg tells you nothing in week three; launch-banner-monday.jpg tells you everything. Include the campaign or the post date and, if you make variants, the purpose — the Bluesky copy and the Dribbble copy should not sit next to each other looking identical.

Keep the variants together. If you export a master, a standard version, a Bluesky version and a Dribbble version, put them in one folder named after the post. Four files with the same stem in four different directories is how the wrong one gets attached at 9 pm.

Delete the rejects. Every rejected export you keep is a candidate for attaching to the next post. When an upload fails and you re-export, remove the file that failed rather than saving it alongside the fix.

The media library is a store, not a scrapbook. It holds what you uploaded, shows you the preview, and lets you confirm the file you are about to attach is the one you mean. It does not organise by campaign, it does not deduplicate, and it does not delete the underlying file when you delete a post in every path — so periodic tidy-ups are your responsibility rather than the system's.

One source of truth for the originals. Whether that is a folder on your machine, a shared drive or a design tool's export, the masters should live somewhere that is not this product. PostHub stores what you publish; it is not a media archive, and treating it as one means your originals are hostage to a deployment.

A five-minute monthly habit — clear out rejects, confirm the masters are elsewhere, check that nothing sensitive was uploaded by mistake — is the entire maintenance burden. Media management that needs a system of its own has already grown past what a scheduling tool should be doing for you.

When the file is not yours

Most media problems that reach support arrive with the same sentence attached: somebody else sent me this file.

It is a HEIC from a phone. Convert to JPG before it goes anywhere near the upload endpoint. The conversion is lossless in the sense that matters for social — you are changing the container, not recompressing from an already-compressed source.

It is a PDF. Export the page you want as an image. Platforms do not accept documents, and a PDF renamed to .jpg will fail the server's type validation even if it passes your file picker.

It is enormous. Four thousand pixels and thirty megabytes from a design tool. Resize first, then compress, in that order — the sequence from earlier in this guide applies to received files exactly as it does to your own.

It is in CMYK. Print-origin artwork will shift colour on every platform that expects sRGB. Convert before you judge the colours; what looks wrong on the destination is often correct in the wrong colour space.

It is a screenshot of a design rather than the design. Ask for the export if you can. If you cannot, crop it, scale the long edge to about 1600 pixels and check the fine text after a test publish — re-encoding softens exactly the kind of detail a screenshot is full of.

It is the wrong shape for Dribbble and Bluesky is in the selection too. Two different constraints on one file: exact 800x600 for one, under about 900 KB for the other. Prepare both variants rather than trying to satisfy both with a single compromise file.

The unifying habit: receive the file, look at what it actually is, and run it through your own export before attaching it. Thirty seconds of normalising someone else's file prevents most of the rejections that arrive as surprises.

Pre-flight checklist

Before you press publish on a post with an image attached, four questions are enough:

• Is it an image, in JPG or PNG, under 10 MB?
• Is it under 976 KB if Bluesky is selected?
• Is it exactly 400x300 or 800x600 if Dribbble is selected?
• Does every selected platform actually accept media of this kind — image versus video, required versus optional?

If all four are yes, media will not be what stops that post. If one is no, you have found the reason before the platform did, and the fix is a re-export rather than an afternoon of troubleshooting.