The current image handling is minimal, there is no rescaling a all and the full image is simply scaled to the width of the post.

This works well until you have images that are wider than the 640px available for posts. There are two important categories of images that pretty much always break this limit: Pictures taken with a digital camera and screenshots. Sites that would benefit from an improvement here would be especially Photo.SE, Arqade, DIY and other image-heavy sites.

The current result of this for inexperienced users is that they put the full-sized image in the post. This means a waste of bandwith for everyone looking at it, and also makes the full-sized image not accessible to non-technical users.

An experienced user will rescale the image before uploading. This takes more time and also makes the full-sized version of the image unavailable for everyone.

A very experienced SE user can work around the whole thing and use the automatically created thumbnails from imgur to create a preview image linked to the full-sized one. This is only known to very few users, it is not discoverable and quite a lot of work.

I'll use a project from a developer that is rather well-known around here as an example how the image handling could be done better: Improved Image Handling in Discourse.

When uploading an image

  • it should be rescaled automatically to the width of the post
  • the image should be linked automatically to a lightbox (or to a new tab) that will show the image in the maximum possible size on the screen.

There should be no need for a user to do any manual work, this should just work automatically.

  • I know that there are existing feature requests on rescaling, but none that I found that propose a lightbox-like solution. Commented Jul 18, 2013 at 12:42
  • Maybe this one? Support showing image in original size in overlay Commented Jul 18, 2013 at 15:42
  • 4
    Man, am I the only one who hates Lightboxes?
    – slhck
    Commented Aug 2, 2013 at 9:10
  • 2
    Hey there. We are looking into automatically linking to images as they are uploaded. This isn't a lightbox, but it's simpler and done commonly enough on the site to be worth it (it's also less divisive than lightboxes). Rescaling the image is a more complex problem, considering that "the width of the post" depends on whether the user is on web or mobile. I'll mark this as status-planned for now, though in practice we're only addressing half of your request. Commented Jul 14, 2015 at 16:12
  • @Thomas still, half more than most feature requests... Commented Jul 14, 2015 at 17:42
  • This is now live! From now on, the image uploader automatically wraps images in a link to themselves. Balpha is to thank for this change. I have updated your question to status-completed, but let me know if you don't find that a satisfactory resolution and I'll update it back. Commented Jul 22, 2015 at 13:14
  • @ThomasOrozco You might want to add this in the form of some kind of canonical answer to the relevant questions (or at least one of them and link to that from the others). Commented Jul 22, 2015 at 13:15
  • @ChristianRau That is very good suggestion ;). Will do. Commented Jul 22, 2015 at 13:16

1 Answer 1


This is now live! From now on, the image uploader automatically wraps images in a link to themselves, which looks like this:

[![enter image description here][1]][1]


Balpha is to thank for this change.

  • 1
    @ᔕᖺᘎᕊ It only includes a link to the image. The reason we cannot render a smaller image is because the "right resolution" isn't a constant (it depends on mobile vs. desktop, etc.). We've investigated using a smaller resolution in the posts, but this is a significantly more complex change, so we're not there yet. Commented Jul 22, 2015 at 13:23
  • Does this only kick in if the image is significantly larger than it would be on the page or does it always create the link? Commented Jul 22, 2015 at 14:05
  • @ChristianRau Always: this changes the markdown (and can therefore be removed), and whether the image is too large or not isn't something we know at markdown generation time. Commented Jul 22, 2015 at 14:13
  • One quirk I discovered: If you add one image, both links use the same number [1]. But when you add a second image, the first image gets two separate numbers (whether it's [1] and [2] or [2] and [3] depends on where the new image is inserted). To test it out, edit in a second image on this post. It bugs my less is more mentality. Also (and I can't think of a good fix for this), I prefer the inline link style ([example text](http://example.com)) and this change makes it a bit harder to edit. Commented Jul 23, 2015 at 17:24
  • 1
    When I see that an image is hyperlinked, I assume it's on purpose: clicking it will lead me to some additional information (such as full size image, or a video from which the image is taken, etc). The new approach defeats this expectation by making everything hyperlinked, most of the time without a reason. The Markdown sources are now uglier too. And all this is to save -- on rare occasion when it's needed -- the trouble of right-clicking and opening full image in another tab? With the new system, I am probably still going to open in another tab, because I need the text of the question too.
    – user259867
    Commented Jul 23, 2015 at 17:34
  • @JonEricson Good point. This is arguably a more generic problem / separate issue: if you used the same link multiple times in a post (images or not), inserting a link or an image actually rewrites those (e.g. if your post is [test][0] [test][0] [test][0]\n[0]: http://test.com, inserting a new link won't preserve the existing one). Commented Jul 23, 2015 at 17:35
  • The point of the feature request was that the embedded image would be a smaller copy, server-resized. This isn't happening, as you said. As long as the full size image is already embedded in the page, an explicit link to the same content brings redundancy and confusion without a benefit.
    – user259867
    Commented Jul 23, 2015 at 17:36
  • Thanks for your feedback @NormalHuman. Here are a few counterpoints I'd like to offer (of course, I'm not trying to convince you that you should like this change, but I hope you'll understand why we made it). 1.: There were other posts that requested it and had positive feedback (here, here, here). 2.: we observed that this was a common pattern on existing posts. (cont.) Commented Jul 23, 2015 at 19:17
  • 1
    (cont.) 3. whether the image displayed in the post is full-size or not is device-dependent (and so is resizing), and the decision to wrap it in an link or not would have to be done at post rendering time (before we know what device is looking at the image), so while conditionally choosing whether to wrap the image in a link would be ideal, it's also significantly more complex (it'd have to happen client-side). Now, we've recently noted that this change interacts poorly with our mobile apps, so there might be some upcoming adjustments. Commented Jul 23, 2015 at 19:18
  • <s>Maybe you could use HTML5's <picture> tag and add the different sizes in <source> tags, and a full-size <img> as a fallback, as well as having the image link to the full-size version?</s> Or you could use <img srcset="...">. Commented Apr 3, 2019 at 3:24

You must log in to answer this question.

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