Stack Exchange’s image hosting arrangement with Imgur has ended - migration complete!

Imgur strips EXIF/metadata from images.

EXIF data/metadata is removed from all images upon upload. There is no setting available to retain the data.

I think we need to maintain that level of user privacy. Pictures from phones can (do) contain a LOT of identifying information and having that automatically removed by the system is important.

Questions

1. How exactly will the lifetimes of the imgur images work? Do the image URLs just insta-rot in April 2024? And when do you expect the images on the new platform to be all copied over by?

   Image links will likely insta-rot [...] we're [...] focused on completing the migration in time. – Kyle Pollard

   [Imgur] plan to give us full control of the *.stack.imgur.com subdomain, which we plan to point at our own servers to take care of the redirection – Kyle Pollard

2. What's going to happen to the pending feature-requests that have to do with images- especially those with relation to imgur hosting? If there are requests that had aspects that were tied to imgur as the hosting platform but can be generalized, should we re-raise the feature-request?

   In terms of extra feature requests, they're out of scope for now as we're just focused on completing the migration in time, but I'm happy to read any if you bring them forward. – Kyle Pollard

3. Will there be any degree of URL / image ID stability? Ex. https://i.sstatic.net/12345.jpg can be translated to new-hosting-domain.com/12345.jpg.

   wizzwizz4 gave an example of a case where this could matter (in puzzles on puzzling that rely on them).

   I keep a list of i.stack.imgur URLs pointing to funny "screenshots" of code (people using their phone to take a picture of their laptop) that I stumble upon in the wild on SO, and while I've been lucky enough to also have kept track of the post IDs so that I can find them again even if the image URLs change, it'd be nice for other reasons:

   I plan on keeping the exact same IDs – Kyle Pollard

4. Is there any possibility of getting Imgur to maintain a basic redirection endpoint?

   I ask this out of consideration for archives like the data dumps, which don't include images. Also like... the rest of the internet. Ex. google search link:i.stack.imgur.com -site:stackoverflow.com -site:stackexchange.com -site:imgur.com <etc.>, which turns up about 10M results. Compare that with searching for pages within SE that link to i.stack.imgur.com which is roughly 82M results. 10M is more than 10% of that. To put it lightly, it would be no small amount of negative impact to the rest of the internet if old links do not auto-redirect to the new links.

   It would suck for there to be no user-friendly, reliable way to get from an i.stack.imgur.com URL on a non-SE site or from the data dump to the new URL on the new hosting service.

   User friendly would be like if you could get Imgur to maintain a basic endpoint where they just redirect a request to https://i.sstatic.net/<path> to the new URL. There are different ways this could happen. If there's image ID stability, then the Imgur redirection endpoint could do it pretty easily. If there's no image ID stability, then you could keep a translation database from old to new image IDs, and the Imgur endpoint could redirect to a Stack Exchange endpoint that does that translation using the translation database.

   I don't expect we'll get redirects from Imgur but I'll ask them. – Kyle Pollard

   can we ask them to just make that a CNAME to some SE server that can then do the redirections? - muru

   This is exactly what they're going to do. - Kyle Pollard

5. Assuming that you'll update links to images in comments, are you going to make sure that the new URLs can still fit within comment length limits for comments that link to images? If not, what's going to happen? unceremonial truncation?

   The comment length is an interesting edge case I hadn't considered, thanks for calling that out. – Kyle Pollard

Reminders

1. Please be careful not to unnecessarily use the thumbnail URLs instead of the original-size URLs when transferring. I.e. don't transfer https://i.sstatic.net/12345m.jpg. Transfer https://i.sstatic.net/12345.jpg.

   We'll be using the original source image, not thumbnails – Kyle Pollard

There were three major pain points with using Imgur as the hosting service. Please make sure these are resolved with the new service:

Networks where Imgur is blocked

Back in my early years of contributing to the SE network, much of it was from my school's network, which blocked Imgur, which meant that I could not view any images in posts from that network. The new image host should either be entirely internal, or on a service that most school or work networks don't block. This has been a pain point since 2011.

The built-in resizer stripping out transparency

There have been multiple complaints about users' images unexpectedly looking odd or incorrect when resized using Imgur's built-in resizer. This is because it strips out transparency, and sometimes decides to render black instead of transparent, resulting in blacked-out images. Please ensure that the new way both 1. has a built-in resizer, as it's a very useful feature, and 2. that it works with transparency. This will also fix this problem with avatar transparency.

The 2 MiB image size limit and unexpected file compression

This has been complained about for a very long time. The standard public Imgur service allows 5 MiB uploads for anonymous users and 10 MiB uploads for registered users, as opposed to SE's 2 MiB. Also, images over 1 MiB would be unexpectedly compressed to very, very small sizes. Please fix this limitation with your new service!

I am honestly surprised this didn't happen years ago. Congratulations to whoever managed to keep it going this long (in both companies).

• When choosing new URLs: be aware that a few multi-part Puzzling questions rely on the codes remaining the same, so it would be nice if you could preserve that.
  • Even better if imgur would commit to keeping the URIs cool – a blanket 301 should be much cheaper than the full hosting.
  • i.stack.imgur.com URLs were nice and short, and could easily be used in comments (unlike Stack Overflow for Teams image URLs). A hypothetical i.sstatic.net would be around the right length, if you were to do this in-house.
• Also good would be if images ended up properly archived, like post text is in the database dumps. That was impractical when you were using imgur, but might be more viable with a new system.
  • And perhaps in a future implementation, way down the line, you could track "what references this" information better than the current "it's just a file store" approach can. But that's hard.
  • Many images on i.stack.imgur.com contain private information that wasn't supposed to be shared publicly. This complicates archiving somewhat – but since information usually becomes less sensitive over time, I would advise that you migrate all the images.
• I'd also love to be able to upload SVGs – which, when appropriate, are smaller, and can have alt text bundled in the file.
  • So long as your new host doesn't re-encode everything (especially not to webp), I'd be satisfied with just the currently-supported file types.

Regarding Sonic the Anonymous Hedgehog's answer

I'm not in favour of increasing the maximum upload size, unless some more automatic work can also go on behind the scenes.
I do see the benefit especially for a new user to be able to send something they just took on their phone - but they will be totally unaware of the extra load that causes for anyone viewing the page. As far as they can see it is the same size as everybody else's photos.

I can think of no instance when the inlined image needs to be full quality - apart from anything else it's only ever displayed at 650px on the main page.

If people less data-savvy post up four or five 5MB images of their garage door for such as diy.se, then everybody visiting it will get a huge data hit. It's rare on non-computer-tech sites like that for anyone to back-edit & inline the imgur m or l instead of the full image.

I'd very much like a future consideration for automatic inlining of a resized, lower-quality 650px wide image automatically linked on click-through to the original - in effect automatically inlining the l. This could be done silently as the post is saved, as currently happens with link renumbering, to save confusing the less-savvy user.
I spend a fair amount of my time doing this manually.

Inlining an l or m takes several steps -
Renumber the 2nd reference
Copy paste the original link
Renumber one reference in that link.
Add an 'l' to the other.

…that's a lot of faff to make the page look almost no different yet save several MB of page load.

It makes sense to keep the original, for times when detailed examination is required, but little sense to make everyone load an image larger than they're actually seeing & before they even know whether or not they're interested in the image.

Not everybody is on gigabit.

An additional thought on this 'automation'.

When a new user uploads an image it will not automatically inline for them. A more experienced user must do this - which on many sites gets done quite quickly; good.

However, the code they get when the new user uploads is only partial compared to an established user.

Then what happens is the established user just plonks an exclamation mark in front & hey presto, working image.

However - no-one ever thinks to add the necessary syntax to enable click through

…so perhaps some consideration needs to also be given to this issue. Perhaps setting the full syntax just without the exclamation mark -

though that makes this happen in the post

I don't have a solution for this, but it does perhaps need looking at.
I think this is going to be the same problem whether or not we incorporate the auto-resize, so I feel it needs considering at the same time.

One additional consideration for automatic resizing - the system needs to be aware of DPI settings.
Modern HiDPI/Retina systems often take screenshots at 144 DPI rather than the old 72 DPI standard. This means they arrive 'double size'.
Perhaps we also need a 'DPI halver' for these images.

Make sure that avatar images that use gifs don't play their animations. Animated avatars are not allowed and the current solution to make them not play their animations is to use imgur-specific query parameters.

See also

• Imgur feature allows animated avatars
• Are animated GIFs allowed as avatars?
• Animated Gif Profile pic on StackOverflow doesn't animate
• Is it possible for us to use an animated GIF as our profile picture or in our personal information?

EXIF data is stripped for privacy reasons, but sometimes there's a genuine need for some specific attributes

Someone already posted about how Imgur strips EXIF data out of uploaded images, and that it's good to do so to prevent privacy leaks.

However, this does create two problems:

Some images require their EXIF data to be rendered correctly, and render incorrectly without it

This question reports a bug where an image renders incorrectly when uploaded to SE Imgur. The answers there contain a visual of how the image is supposed to look like and state that stripping out the EXIF data causes the image to render incorrectly.

Some sites, such as Photography, use the EXIF data to obtain crucial details about a photograph

As this post says, on Photography, having to constantly ask post authors for how they took the picture (e.g., ISO, aperture, shutter speed, etc.) and what camera make/model they used can be a big pain, and it's much easier to just look at the image itself for this information.

Honorable mention: past (now fixed) Imgur bug with images displaying incorrectly rotated

Essentially, some image editing tools, when a user issues a command to rotate an image, keep the image as is and simply modify an EXIF attribute to display the image rotated. This resulted in a past bug where stripping out the data caused the image to incorrectly display in its un-rotated form. This was fixed by Imgur, by it searching for this specific attribute and physically rotating the image server-side, then stripping out the EXIF data. At the very least this behavior needs to be copied over, but that won't address the above two issues.

Again, I understand that removing EXIF data can be important for privacy reasons. However, removing all of the data wholesale creates problems. In your new image server, please only strip out specific attributes (such as GPS location) while leaving ones necessary for the image to render properly (such as those in the first and last sections above), and those useful to sites like Photography (those in the second section above).

Chat uses Imgur for image uploads, so I assume that this will require changing it to use a different service?

Also, if old images aren't redirected somehow, every single image in chat will break once the service shuts down.

A long-standing privacy issue has existed with users being allowed to include images from arbitrary external domains in posts and chat. This can be used to track users, among other risks.

Additionally, off-site images can rot or have their contents changed. And while this is a more minor issue, my school district (and like others using the same software) cuts off internet access if banned applications/websites are detected, and off-site hosted images from Discord's CDN or NSFW websites can cause this to happen without ever leaving Stack Exchange.

If you'll already be needing to rehost a significant majority of images on the site, are there any plans to finally disallow off-site image hosting on untrusted sites?

This is a follow-up question to Starball's post:

1. Please be careful not to unnecessarily use the thumbnail URLs instead of the original-size URLs when transferring. I.e. don't transfer https://i.sstatic.net/12345m.jpg. Transfer https://i.sstatic.net/12345.jpg.

We'll be using the original source image, not thumbnails – Kyle Pollard

What about posts that purposely include both thumbnails and the original image, or posts that include the thumbnails only? Will the images in these posts be transferred intact with no size changes? I often add thumbnails to my post (example) and link them to the original image if the original image is too large (in either resolution or file size) for the post, like this:

[![screenshot][1]][2]


  [1]: https://i.sstatic.net/12345m.jpg "thumbnail"
  [2]: https://i.sstatic.net/12345.jpg "original"

As an alternative to Imgur doing redirections once the contract ends, can we ask them to just make that a CNAME to some SE server that can then do the redirections? Or even license the stack.imgur.com subdomain to SE so that SE can maybe even continue using it?

The former would be a trivial expense for them, the latter maybe even a microscopic revenue source.

feature-request

Currently, I use url:imgur to search for posts that have images, which gets most but not all of them. (It really only works because the default image format is a linked image.) This can't possibly work after the migration, so it would be nice to have an alternative built into search that returns everything containing <img, and maybe also the opposite, something that finds posts without any images.

I guess this might count as a "wholly new site feature" and be out of scope but I'm asking anyway.

Expanding a comment - Imgur uploads, outside the occasional 'I need a quick and easy place to throw an image up' gets used in a few places outside the main site. While I guess it’s 'easier' on your end to find the images, with raw database access, I'm curious about the 2-4 (or more!) different image upload methods you have, and consideration for more unusual locations.

1. At some point Imgur turned into the preferred avatar upload space over (legacy) Gravatar. This seems to use a slightly different uploader from the main site - do you have a plan to back up and make available noncurrent avatar images?

2. In theory, moderator messages can, and sometimes do include images, and while they have limited utility in the long run, depending on 'how' you fix the images, these might be broken. Looking at the source of an email of a test moderator message I sent

<p>Testing to see if images on mod messages are mailed and how it’s handled<=
/p>
<p><a href=3D"https://sg-links.stackoverflow.email/ls/click?upn=REDACTED" rel=3D"nofollow noreferrer"><img src=3D"https://i.sstatic.net/zZsT=
u.jpg" alt=3D"enter image description here" /></a></p>
<p>Regards,</p>
<p>Super User Moderation Team</p>

You might break embedded images in emails - and I do recall some users use it for reference. There isn't anything you can do, but fixing broken ones on moderator messages too might be something to consider. If nothing else, give moderators something to point at if users complain ;)

3. 'Regular' chat uses a really old uploader version with less functionality and images are essential on chat. The "new" mobile chat has none (which is annoying, but I understand out of the scope of this). While getting any attention to chat is like pulling teeth, breaking images and image upload on chat would be a very bad thing. It feels like maintaining a single universal upload system is a good idea and this is an opportunity to do it

4. While scanning through Stack Overflow for Teams for Imgur links might be a no go, since Stack Overflow for Teams provides integration for third-party things, maybe having a tool to 'fix' these links based off the solution you pick might be good?

An internal proof-of-concept will inform the image hosting provider we ultimately settle on.

Is self-hosting not a viable option?

Forgive me if I'm being daft here, but I can find very little about that possibility and eventual discussion here on Meta, with the first questions tagged with images announcing this very cooperation with Imgur.

Here is an answer getting into the problems with external hosting.

Of course, self-hosting I assume opens up a different can of worms, but this network is based on smart people dealing with software, and I imagine self-hosting would make migration a lot easier, too.

In my SEDE querying of SO, there are a number of posts which link to i.stack.imgur.com images in code (code blocks and probably inline code as well) and not in actual images. Ex. as example images in Stack Snippets. I actually discovered this by accident when investigating what types of query parameters were being used in such URLs- they showed up in my SEDE query because of people using their avatar images as example images in Stack Snippets.

Will these URLs in code blocks be edited as well to their new locations?

Posts deleted as spam or abusive should continue to have their images automatically deleted, as they currently are with Imgur

There is currently a feature with the current Imgur uploader whereby if a post gets deleted as spam or rude or abusive (automatically in response to receiving the threshold number of flags from the community or a single one from a moderator), any images that are embedded in it and uploaded at about the same time as when it was posted will be deleted from Imgur's servers.

This is important because many of these posts use images - for instance, there was a past case of a troll filling a site with offensive images, and many spammers use images as part of their posts.

Please make sure that this feature is copied over to the new image host.

I have an idea that can improve the migration process a bit.

Considering that Imgur tracks when an image that they host is being viewed, or at least the amount of times it was viewed, my suggestion is simple: do not migrate images that were never viewed, or with only the one view of the uploader after it was uploaded.

Advantages:

• Saving resources. No need to store something that's not being in use.
• Even more important: privacy. Personally I've uploaded images then on second thought didn't use it, and I'm certain others uploaded sensitive things by mistake, and corrected it without ever actually posting the image URL, hence adding images that were never viewed.

feature-request

It would be great if the images could be served with the proper Access-Control-Allow-Origin headers so that we can do some readbacks on it, e.g., call getImageData() or toDataURL() from a <canvas>.

It would definitely be useful for Stack Overflow, where for years we had to work around that issue by using other services, like Dropbox, or other images like the ones coming from Wikimedia, but I guess this could also be useful to a couple of other sites.

Depending on the method used, editing posts can count as a modification, allowing users to change formerly locked-in votes.

Are there plans regarding if votes will be unlocked as a consequence of this?

This might be out of scope, but for any SE Imgur images in SOfT, will those be fixed too? Or not?

Maybe this is a little bit lazy, but for years whenever I've wanted to host an image, I'd upload it via the Stack Exchange uploader and copy/paste the Imgur link to whatever site I was using (Reddit, some forum, etc.), without posting the image to Stack Exchange sites.

I didn't think much of it when Imgur was hosting the images (it seemed equivalent to uploading images to Imgur directly). But I'm now a bit worried that all those images used only at non-Stack Exchange sites will break. Is there anything I can/should do?

Edit: What happens now when I link to images outside of Stack Exchange (using a newly uploaded image):

Some of the images used in the Help Center are also stored on Imgur. Will they be migrated without exception?

We used to have a bot on Super User's main chatroom, and there's a significant amount of nostalgia to some of the content there. It used to serve out images on request and I was (as time/spoons/attention span permitted) building up a list of commands and the associated images, reuploading any that weren't hosted on Imgur and so on. While there's time to the sunsetting.

1. would there be an easy way to 'cut' over to the new host
2. what would be the 'ideal' way to archive these things if I'm working on it before things are firmed up?

Some technical questions coming in! Now I knew you said technical and implementation questions are limited to answer but these are very broad, I am sure you can answer these.

Will there be an API?

Could I create and delete images automatically? You could bulk-upload images which might be useful sometimes, and it will make it possible for moderation bots that automatically delete inappropriate images.

More advanced UI?

See the current image uploading UI is very basic, would there be no new UI or would you renovate it a little bit to make it feel more modern? Like I assume we'll be able to delete images so a button would be needed for that? Will you have different menus or just one pile of buttons?

Image support?

Will PNG, JPEG, GIF, and many more image formats be supported? Or will it only be PNG? Would more obscure formats like WebP be supported?

Statistics?

Will there be a page with "x images per day/week/month/year" or "PNG makes up x percentage of images"? Statistics could be used for a wide range of things and would be easy to implement, I know as a software developer, you would just need to look at your list of images, filter them, and count them.

Advanced URLs?

Would you be able to group two images so "newdomain.com/group/img1.png", "newdomain.com/group/img2.png" and so on because I could find some uses for that and again it would be fairly simple to implement as you would only need to really ask for an alternative path or perhaps use a group name and then have the modified URL go through all your normal functions and classes.

I am going to leave it off at there because I do not want to get too specific, hopefully your team have great success! I wish you good luck!

(Also for the image hosting provider, CubeUpload and ImgBB are two good options, each with their tradeoffs, the company behind ImgBB is unknown while CubeUpload is apparently maintained by three British developers, both of these options however might not be scalable enough for SE)