I noticed at the start of August 2018 that new images like https://i.sstatic.net/MJrvX.png no longer resize when an m is placed before .png.

  1. Original image:
    Auto shrunk by page formated to about 609 pixels (desktop), but still full size.

  2. l suffix:
    Should reduce image to 640 pixels wide.
    ~~ FAILS ~~ default

  3. m suffix:
    Should reduce image to 320 pixels wide.
    ~~ FAILS ~~ default

  4. t suffix:
    Should reduce image to 160 pixels wide.
    ~~ FAILS ~~ default

  5. s suffix:
    Should reduce image to 90x90 pixels.
    But notice that image displayed is from the middle of the original image, where there is no detail -- ~~ FAILS ~~

Additional proof that this once worked on PNG images can be seen in: Preserve image transparency when resizing images

Please restore this resizing functionality ASAP.

  • 8
    I had this problem, too. The m addition did nothing and s made the image smaller but also cropped it.
    – Catija
    Commented Aug 11, 2018 at 12:08
  • Stack Overflow can ask Imgur to restore the functionality, but I'm not sure they can "restore this resizing functionality", ASAP or otherwise... Commented Aug 12, 2018 at 14:28
  • 11
    @HereticMonkey, Stack Exchange pays Imgur to do a job, they can dang well pressure them to stop the malfunction. And, Stack Exchange is probably one of their bigger paying customers. ...Or Stack Exchange can switch providers, or move the capability in-house. Commented Aug 12, 2018 at 21:24
  • I don't know why the following post doesn't appear in the related column, maybe lack of votes? But I have found it useful. Related: The order of the attributes in the <img/> element matters when it shouldn't Commented Nov 1, 2018 at 8:11
  • 3
    @Catija could you as employee please clarify the position of the Stack Overflow company on this issue? Commented Jan 17, 2019 at 9:57

6 Answers 6


This bug is very annoying when trying to create or fix posts with overlarge images. We used to be able to display a reasonably shrunk picture that linked to the full size one.

Here's a temporary workaround until this bug is fixed:

Refer to the allowed HTML FAQ.

Use markup like:

[<img src="https://i.sstatic.net/MJrvX.png" width="320" height="30" alt="wide demo pic">][2]
  [2]: https://i.sstatic.net/MJrvX.png "Click for larger image."

which yields:

wide demo pic .

-- With:

  • a useful alt parameter
  • Hover text.
  • a convenient link to the image, full-sized.
  • 4
    Note: If you don't include the height="30" attribute, the image will preserve its aspect ratio instead of being squished. Awesome Poodles has a reason for including it, but hasn't yet explained why.
    – Cool Fool
    Commented Sep 13, 2018 at 23:58
  • @CoolFool, I did explain to you semi-privately. The main reason is to illustrate the allowed attributes in the only allowed order. A second reason is so the image is more prominent as an image (rather than some thin kind of horizontal rule). Commented Sep 14, 2018 at 0:06
  • Why not add a second example to show the best of both worlds? I don't know why SE decided to only allow a specific order (that's not part of HTML), and it looks better with the original aspect ratio. I certainly don't want to manually calculate the height for every image I edit.
    – Cool Fool
    Commented Sep 14, 2018 at 0:35
  • @CoolFool, because I don't see a pressing need, and the KISS principle. ... As for SE, I think it's a combo of whitelisting ease and the same reason that brown M&M's are forbidden. Commented Sep 14, 2018 at 0:46

This has been fixed!

Thank you so much for your patience with this. Moving forward, all images uploaded to the Stack Exchange imgur will be sizable using the URL adjustments indicated in the question (see below for examples).

You'll notice I said "moving forward". Any images uploaded during the outage (7 August 2018 until 19 April 2019) will need to be re-uploaded to imgur for the resizing to work correctly as the additional image sizes weren't created and there's no way to fix this.

From the imgur response to our bug report:

There was a problem with a few of the servers that had autolaunched using the wrong IAM profile in AWS, resulting in their not being able to properly write to S3 as expected. Because some of the servers were working correctly, this made the occurrence incredibly random.

The team over at imgur were amazingly helpful in getting this done for us quickly. Within 24 hours of notifying them, they identified and fixed the issue. We really appreciate their effort! You may ask, "why did it take nine months to fix, then?" - to which I'll say, it unfortunately and unintentionally went through something similar to the Vogon bureaucracy to get to imgur. Before finally getting sent to imgur, the task ended up being:

signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters.
~Douglas Adams, The Hitchhiker's Guide to the Galaxy

Thanks for participating in the public inquiry part of that process. This error has reduced the number of images I personally added to posts so I'm particularly glad that it's fixed.

We're sorry for the delay but glad that it's up and running now.

Thanks to the users who caught this here on our various meta sites and to Geoff for knowing who to contact.

Size test:

Full size:
Full Size

Large size (l):
Large Size

Medium Size (m):
Medium Size

Tiny Size (t):
Tiny Size

Big Square Size (b):
Big Square Size

Small Square Size (s):
Small Square Size

There's also Huge (h) but it looks just like the full size because the image is big.

  • 2
    And it only took 6-8 weeks
    – Richard
    Commented Apr 19, 2019 at 23:01
  • against the Vogon bureaucracy, this is to be considered a resounding success, well done to all involved. i've heard of this random symptom with aws before, not a pretty bug for the people chasing those wires.
    – ocæon
    Commented Apr 20, 2019 at 0:33
  • 5
    So what was the "unintentional" thing that happened that caused it to not get sent to Imgur in a timely manner? Commented Apr 20, 2019 at 0:35
  • 2
    Well, its worth considering that they did switch ticketing systems over the period, imgur has been in use as our default image host for a very long time, so digging up the old relic that knows how it works might be difficult... Commented Apr 20, 2019 at 15:08

Yet another workaround might be adding a query string like ?s=xyz (with xyz = 16, 32, 64, 128, 256 or 512) after the name of the image to change it from gSpBi.png to (eg) gSpBi.png?s=128. I.e I just added the query string ?s=128 right after .png. Attention: sometimes part of the top and bottom are not shown (I think it depends a bit on the actual image you're using).

Some examples of using such query string in an image, for xyz = 16, 32, 64, 128:

enter image description here (?s=16)    enter image description here (?s=32)    enter image description here (?s=64)    enter image description here (?s=128)   

Btw, the above also shows that you can even insert some text in between 2 images, though such text seems to have these limitations (at least I have no idea yet how to get around those):

  • cannot have text that spans more then a single line.
  • the vertical alignment of the text is always at the bottom of the image.
  • the spacing between the image and text can only be set using &nbsp;.

Note: Similar to what is mentioned in another answer, make sure to respect some specific HTML formatting syntax, in order to be able to use the img HTML tag. E.g. to create these 3 variations (sizes) of an image:

Babou, aka My Patou Babou, aka My Patou Babou, aka My Patou

Here is the HTML source that created the previous 3 images:

<img src="https://i.sstatic.net/gSpBi.png" width="216" height="180" alt="Babou" title="My Patou">
<img src="https://i.sstatic.net/gSpBi.png" width="270" height="225" alt="Babou" title="My Patou">
<img src="https://i.sstatic.net/gSpBi.png" width="135" height="113" alt="Babou" title="My Patou">
  • The s parameter crops the image into a square. That's no good for most images, but okay for some. You can also use select other integers -- 16, 32, 64, 128, 256, 300, 500, 512, and 900 -- for s. Commented Oct 29, 2018 at 20:57
  • Thank you for this! In my particular case I'm also interested in the minimization of the loading time (and data volume) for users of mobile devices or living in places in the world with less-than-awesome connection speeds, or with explicit data charges. I'm curious if this work-around does the resizing on the server side (as the imgur feature did), or does it download the full image size to the user's device first, then do the resizing there?
    – uhoh
    Commented Oct 30, 2018 at 1:50
  • 1
    @uhoh, it's the former (the s parameter, and the previously working suffixes, do save bandwidth). Commented Oct 30, 2018 at 6:26
  • Okay that's great news! Can you change "former" to "server" in your comment? Thanks!
    – uhoh
    Commented Oct 30, 2018 at 6:28

It's always worth trying the m attribute first, as it still sometimes works.

I posted on the photo meta before discovering this post - Imgur image resize not always working - the linked question did resize one image, but even after several attempts with fresh uploads it refuses to resize the other. [s and b work, but not m]

The trouble with using the img tag instead of the m is that the downloaded image size is the same for the end user, whereas the m would significantly reduce the download itself, unless they click through for the full size.

The only real [& utterly PITA] solution I can see right now is to download the full-size image, re-size in the image manipulator of your choice & re-upload it, then you can link [1] and [2] after the fact to each size, as a totally separate upload/file name.

  • The create new m size image feature has stopped working, but if there are already existing m sized images, they will still display. Is there any chance that you or someone have already generated the m version of AwVru? It's not the display function that has stopped, it's only the generation of new m size versions of images that's gone.
    – uhoh
    Commented Dec 18, 2018 at 14:09
  • 1
    I've no way to tell. Testing a brand new image upload, it gives s & b but not m, so you may be right.
    – Tetsujin
    Commented Dec 18, 2018 at 14:18
  • Yep, the m worked for me a little while ago. It's intermittent. Hopefully, Imgur is A/B testing a fix or something... Commented Dec 26, 2018 at 1:57

Confirming this is still broken, and sharing my workaround.

Imgur still does the resizing, but very unreliably. I just finished successfully embedding three images with thumbnails in this post. There’s something wrong with their code or their infrastructure, and it’s failing for a high percentage of uploads, but not all of them.

The first two images in that post that I uploaded (the second and third in the post) came back without resized versions being generated, but both worked on a second try. Notice though that they only have t versions — the m versions generated are still uselessly full-sized.

The first image (last successfully uploaded) took dozens of tries. The first time it worked at all produced a useful m size but no true t size. Subsequent uploads produced no resized images. After dozens of tries I got a URL that finally gave a thrumbnail (though no medium version), and that was good enough to match it with the other two images.

A workaround is to just reupload until it works

Open a new blank question and just go to town, uploading until you get a URL that also has the resized version you need. A blank question box is easier to manage than working in the middle of other text and images, and is marginally faster since the JS has to chew on less preview.

This consumes Imgur URLs and storage, but Stack Exchange and Imgur will have to suck that up until they deal with the bugs in their resize process. Some posts need thumbnails or reduced images, and browser-based resizes aren’t always what the post needs.

  • Re-uploading is not a good option in case you just want to edit an existing post of someone.
    – Robert
    Commented Apr 18, 2019 at 9:46

The Stack Exchange network also allows direct embedding of images, as well as the handy image shortcut. Until this issue is fixed, you can use direct image embedding as a workaround. The following code produces the image below it:

[<img src="https://i.sstatic.net/MJrvX.png" width="320" alt="wide demo pic">][1]

[1]: https://i.sstatic.net/MJrvX.png "Click for larger image."

wide demo pic

Notes: Stack Exchange style is to place the link URL at the bottom of the post, after all the remaining paragraph text (see the markdown source of this post as an example). Also, you will get better results across both browsers and mobile devices if you don't include the optional height attribute (see below).

From What HTML tags are allowed on Stack Exchange sites?:

img Attributes

The following attributes are allowed on the <img> tag, but note that the mobile theme enforces a maximum width of 90%, so specifying a height might not scale the image proportionally on the mobile sites.

The attribute order is important! Using a different order (e.g., height before width) will strip the tag!

width="" (up to 999; do not include the 'px' extension)
height="" (up to 999; do not include the 'px' extension; see note above)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .