The Instagram API Image Requirements Meta Enforces at Upload

What are the Instagram API image requirements?

Four rules make up the Instagram API image requirements, and Meta prints all four in one block under "Image Specifications" on the POST /<IG_ID>/media reference: JPEG format, 8 MB maximum file size, an aspect ratio inside a 4:5 to 1.91:1 range, and a width between 320 and 1440 pixels. Quoted as Meta publishes them:

Format: JPEG

File size: 8 MB maximum.

Aspect ratio: Must be within a 4:5 to 1.91:1 range

Minimum width: 320 (will be scaled up to the minimum if necessary)

Maximum width: 1440 (will be scaled down to the maximum if necessary)

Height: Varies, depending on width and aspect ratio

Color Space: sRGB. Images using other color spaces will have their color spaces converted to sRGB.

The Content Publishing guide repeats the format rule in blunter language under its own Limitations heading: "JPEG is the only image format supported. Extended JPEG formats such as MPO and JPS are not supported."

Read the block again and a split appears. Two of these rules reject the request. Two of them quietly rewrite your file. Format, file size and aspect ratio are checks, and a failure comes back as an HTTP 400 with a code and a subcode. Width and colour space are conversions, and Meta says so in the parentheses: scaled up, scaled down, converted to sRGB. Nothing tells you it happened.

That distinction decides how you validate before you call the API. You can catch the first group by reading the error. You can only catch the second group by measuring the file yourself.

Which error code does each violation return?

Every image failure Meta documents arrives as HTTP status 400 with a JSON error object carrying code, error_subcode, error_user_title and error_user_msg. The Instagram error codes reference maps them one to one.

The sample error Meta prints at the top of that reference is the file size one, and it is worth copying verbatim because the wording differs from the spec sheet:

{
  "error": {
    "message": "The image size is too large.",
    "type": "OAuthException",
    "code": 36000,
    "error_subcode": 2207004,
    "is_transient": false,
    "error_user_title": "Image size too large",
    "error_user_msg": "The image is too large to download. It should be less than 8 MiB.",
    "fbtrace_id": "A6LJylpZRKw2xKLFsAP-cJh"
  }
}

One row of that table carries a mistake in Meta's own docs. The Recommended Solution column for 36001 subcode 2207005, the format rejection, reads "Possible permission error due to missing permission or expired token. Generate a new container and use it to try again." That is the solution text for code 24 subcode 2207006, a completely different failure, pasted into the format row. A PNG does not become a JPEG when you refresh a token. Ignore the solution column on that row and read the user message instead.

Is the limit 8 MB or 8 MiB?

Meta publishes both numbers on two live pages. The media reference says "File size: 8 MB maximum." The error codes reference says the image "should be less than 8 MiB" in the sample response, and the Recommended Solution column for the same row says "Image exceeded maximum file size of 8MiB."

Those are not the same ceiling. 8 MB is 8,000,000 bytes. 8 MiB is 8,388,608 bytes. The gap between them is 388,608 bytes, which is a band about a third of a megabyte wide where the spec sheet says no and the error text says yes.

Build against 8,000,000 bytes. The lower of two published limits is the one that cannot surprise you, and the margin you give up is small next to a publish that fails at the container step. If you are compressing on the way in, target something well under it: a JPEG that lands at 6 MB survives a re-encode on Meta's side without approaching either number. The same defensive habit applies to the 2,200 character caption ceiling and its 20 @ tag sub-rule, where the field is checked at container creation rather than at publish.

What happens when the image is too wide or too narrow?

Nothing you can catch in the response. Meta resamples the file and continues.

The minimum width is 320 pixels and the maximum is 1440, and both lines end with the same promise: the image "will be scaled up to the minimum if necessary" and "will be scaled down to the maximum if necessary." No error code exists for either direction. A 4000 pixel wide photograph is accepted, resampled down to 1440, and published at a resolution you did not choose. A 200 pixel thumbnail is accepted, stretched to 320, and published soft.

Height is not a fixed number anywhere in the spec. Meta writes "Height: Varies, depending on width and aspect ratio", which means height is a consequence of the two rules that are enforced rather than a rule of its own. Pin the width at 1440 and the aspect ratio at 4:5 and the height follows at 1800 pixels, the tallest frame the feed endpoint accepts.

Colour space behaves the same way. Anything that is not sRGB gets converted, with no warning and no error. A Display P3 export from a phone or a photo editor publishes fine and publishes duller than it looked on your screen. Convert to sRGB before upload so the conversion is one you controlled. The same principle drives the pixel dimensions that hold up across the Instagram surfaces: pick the size Meta will not touch.

How do the API rules differ from what the Instagram app accepts?

Meta gives the app a different set of numbers on a different page. Instagram's Help Center article "Image resolution of photos you share on Instagram" tells people to "Upload a photo with a width of at least 1080 pixels with an aspect ratio between 1.91:1 and 3:4."

Set the two side by side.

The tall edge is the one that bites. 4:5 is 0.8. 3:4 is 0.75. A 3:4 portrait crop that the app takes without complaint comes back from the API as code 36003, subcode 2207009, because it falls outside the documented range. Anyone porting a phone workflow into an API workflow hits this first.

The width rules stop in different places. Both documents start at 320, and the Help Center says a photo narrower than that is enlarged to 320. Above it they diverge: the API scales anything over 1440 down to 1440, while the app sizes anything over 1080 down to 1080. Export at 1080 pixels wide and neither document has a reason to touch the file. AdaptlyPost publishes to Instagram through this API, so the same ceiling applies to anything scheduled rather than posted by hand.

Two more app features are absent from the API by design. The Content Publishing guide states plainly that "Shopping tags are not supported" and "Filters are not supported." Neither returns a helpful error, because neither parameter exists.

Which rules change for stories, reels covers and carousels?

The 8 MB ceiling and the JPEG rule hold everywhere. The aspect ratio rule does not.

Stories drop the enforced range entirely. Meta writes only that it "recommended 9:16 to avoid cropping or blank space", which means a square image publishes as a story with bars rather than an error.

Reels covers crop twice. Meta says that if the cover is not 9:16, "we crop the image and use the middle most 9:16 rectangle as the cover photo for the reel", and that sharing the reel to feed triggers a second crop, "the middle most 1:1 square." Anything important near an edge is gone by the time it reaches the grid.

Carousels ignore the aspect ratio of every slide but the first. The guide is explicit: "Carousel images are all cropped based on the first image in the carousel, with the default being a 1:1 aspect ratio." Order your children deliberately, because slide one sets the frame for all ten. That constraint sits alongside the container count and publish quota that govern a carousel, where a ten image carousel still spends one publish. And if you are setting alt text in the same request, the alt_text field carries its own separate ceiling that has nothing to do with the image itself.

Frequently asked questions

Does the Instagram API accept PNG images?

No. Meta writes "JPEG is the only image format supported" in the Content Publishing guide. A PNG returns code 36001, subcode 2207005, with the message "The image format {current-image-format} is not supported. Supported formats are: {format}."

What is the maximum image file size on the Instagram API?

Meta publishes two figures. The media reference says "File size: 8 MB maximum." The error codes reference says the image "should be less than 8 MiB", which is 8,388,608 bytes. Build against the smaller number, 8,000,000 bytes.

Which aspect ratios does the Instagram API reject?

Anything outside a 4:5 to 1.91:1 range. That rejects 3:4, 9:16 and 2:1 on feed images, and returns code 36003, subcode 2207009.

Does a 4000 pixel wide image fail on the Instagram API?

No. Meta scales it down to the 1440 pixel maximum and publishes it. No error code exists for an out of range width in either direction.

Are MPO and JPS files accepted as JPEG?

No. The Content Publishing guide names them directly: "Extended JPEG formats such as MPO and JPS are not supported."

Do story and carousel images follow the same aspect ratio rule as feed posts?

No. Stories have no enforced range published, only a 9:16 recommendation. Carousel slides are cropped to match the first image in the carousel, with 1:1 as the default.

What height does an image publish at through the Instagram API?

Meta does not fix a height number in the spec, it only writes "Height: Varies, depending on width and aspect ratio." Height comes out of the two rules that are actually enforced, width and aspect ratio, rather than standing as a rule of its own. Push the width to the 1440 pixel maximum and the aspect ratio to 4:5, and the image publishes at 1800 pixels tall, the tallest frame the feed endpoint accepts.

Can you trust the Recommended Solution column in Meta's error codes reference?

Not on every row. The Recommended Solution text next to code 36001, the format rejection, describes code 24, a permission error, and tells you to generate a new container and try again. A PNG does not turn into a JPEG when you refresh a token, so read the error_user_msg field for that row instead of the solution column.

Does a reels cover photo get cropped more than once?

It can be cropped twice. Meta crops any cover that is not 9:16 down to the middle most 9:16 rectangle first, then crops it a second time to the middle most 1:1 square if the reel is also shared to feed. Anything placed near the edge of the original frame is gone by the time it reaches the grid.

Does Instagram's app enforce a file size limit like the API does?

The Help Center article on photo resolution does not publish a file size number at all. Only the Graph API documents one, 8 MB in the spec and 8 MiB in the error text, so the file size ceiling is an API only rule with no published app equivalent.