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

Question

Update on the Imgur migration, May 28th 2024: Migration complete!

As of today, we are pronouncing the work associated with the Imgur migration "complete" for all intents and purposes. There are still some minor trailing issues that we intend to iron out over the next few weeks, and if you see anything out of the ordinary, I would encourage you to create a new post to document it. At this time, we have:

• Created a new image uploading service at i.sstatic.net, mirroring the functionality of the historical Imgur uploader.
• Migrated all images from Imgur to our new Stack service.
• Changed image uploaders on Stack Exchange sites, profile pictures, chat, and other stray uploads/uploaders.
• Built out and tested new architecture that can serve as a template for future on-site services.
• Converted Imgur URLs appearing in all historical Stack Exchange posts, comments, chatrooms, and other miscellaneous locations to new i.sstatic.net URLs.

The team is proud of this transition, and we're thrilled to say we met all major goals we set out to achieve. While there's still a little bit of cleanup left to do here and there, these are almost all behind-the-scenes tasks like data cleanup, log performance, monitoring touchups, and the like. We'd like to extend our sincere gratitude to our colleagues at Imgur for their considerable help along the way.

Thanks for following along! If you've got any further questions, requests, bugs, complaints, comic relief, or compliments to the chef, please make a new Meta post - this one will no longer be monitored for feedback after today.

Update on the Imgur migration, May 15th 2024

The work described in the Imgur URL migration post will be under way shortly. The rollout will take place gradually over the next week or so, give or take a few days. Please report if you run into any issues loading images from Stack Exchange via i.sstatic.net.

Update on the Imgur migration, May 7th 2024

Last week, we completed work migrating existing images out of Imgur into our new image service. Starting next week, we are moving into the final phase of the migration, and will begin rolling out updates to replace Imgur links (i.stack.imgur.com/<image ID>) with the new i.sstatic.net domain.

Similar to the initial rollout of the new image service, we are planning a staged rollout for the final phase, so that we can monitor for any issues during the rollout process. For more information, please see this Meta post.

Update on the Imgur migration, April 29th 2024

As of today, we have rolled out the new image uploader to chat. It looks like this deployment is stable and holding well, and we will continue to monitor error rates, as well as Meta Stack Exchange. This deployment concludes phase one of the migration. All image uploaders across the Stack Exchange network should now point to our internal image hosting service.

We are now transitioning to the next phase of this project. Our priority is now to migrate images from Imgur and update the corresponding URLs across the Stack Exchange network. We plan to provide you with some advance warning once we know when we will be editing old Imgur links to point to our image hosting service - this date is not yet firm.

Update on the Imgur migration, April 25th 2024

As of today, we have rolled out the new image uploader to Stack Overflow, Metas, and the international Stack Overflow sites, and plan to transition chat to the new uploader early next week.

We'll keep a close eye on the error rate to ensure a smooth transition as we mark the completion of the migration's initial phase. There is still work to do, and your patience and support throughout this project is greatly appreciated. Rest assured, we will continue to keep you updated on ongoing progress.

Update on the Imgur migration, April 23rd 2024

As of today, we have rolled out the new image uploader to every site, excluding Stack Overflow and international Stack Overflow sites. We will monitor the error rate and update when the full transition is complete.

Update on the Imgur migration, April 15th 2024

Due to an elevated error rate discovered at launch time, we delayed the network-wide deployment of the new image uploader from its planned time during the week of April 8th (last week, as of this update). Our new plan is to enable the image uploader on all non-Stack Overflow sites this week, followed by Stack Overflow sites early next week. This plan may shift a few days in either direction as needed to accommodate internal release scheduling. With the exception of the modified release timeline, all the details from the below update remain accurate.

Update on the Imgur migration, April 8th 2024

This week, we will wrap up the first phase of our rollout process by deploying the new image uploader to all sites network-wide. Beginning today, all sites and their Meta sites except Stack Overflow and non-English Stack Overflow sites will use the new image uploader. Later in the week, we will complete the rollout by deploying the new image uploader to all remaining sites, including Stack Overflow.

Once the rollout is complete, all new images uploaded to the main sites should use the new i.sstatic.net image hosting endpoint. (For Chat fans - hang on a bit longer, it’s coming.) As always, please let us know if you encounter any unexpected issues, preferably on a new bug report Meta post.

We are currently on track to complete all required work for this migration on time.

Update on the Imgur migration, April 3, 2024

The first phase of our rollout process, detailed in the update below, is now under way. This will be a staged rollout, beginning with a few smaller sites around the network to ensure that everything works as expected. Please let us know if you encounter any unexpected issues, preferably on a new bug report Meta post.

Update on the Imgur migration, March 13, 2024

As we have outlined in this post previously, we are working towards an in-house solution for Stack Exchange’s image-hosting needs. This message is to provide an update on that process.

To date, we have successfully completed the following:

• i.sstatic.net will be used as our new image upload endpoint
• Updated image uploaders via profile pages, post-editors
• Support for uploading photos from external URLs
• Image resizing with s|m|l and additional resizing with ?s= parameter
• Sensitive EXIF data removal

There is still a lot to be done, but we are working diligently and believe all should be in place before the migration so that this transition does not disrupt the daily workflow of the network.

Our current plan is to switch over to the new image uploader within the next few weeks. This will be a staged rollout, beginning with at most a few smaller sites around the network to ensure that everything works as expected. We’ll then roll the new uploader out network-wide. Following that, we will begin the process of transferring existing Imgur images into our new image hosting service.

We will continue to update this post during each phase of the migration to our own in-house image hosting.

---

Original post (Stack Exchange’s image hosting arrangement with Imgur is ending - advance notice)

Since 2010, Imgur has provided image hosting services to Stack Exchange, but that hosting contract with Imgur comes to an end this upcoming April 2024. This April will conclude a 13-year-long successful relationship between Imgur and Stack, for which the whole company has been deeply grateful. However, Imgur no longer provides an enterprise image hosting product, and therefore, it has come time to find an alternative solution.

This post serves as your advance notice that this change is coming down the pipeline. This post is coming to you very early - so you have time to prepare. Here’s a rough sketch for how the next few months are going to look.

We are working on a plan to develop a solution to the image hosting problem. The exact implementation details are still being finalized, and we are in the research and discovery phase for a new image hosting solution. An internal proof-of-concept will inform the image hosting provider we ultimately settle on, and we expect this preliminary work to conclude some time in December of this year. Once our image hosting concept is proven out, we will transition to developing the solution we’d like to hold for the long term. We are aiming to complete core work on this new solution before the end of March 2024. However, as we are in the proof of concept stage, this schedule may shift considerably.

Some time in late December or early January, after proof-of-concept work completes, I will update this post to contain more details on how our solution will work, the sort of impact it will have on the network (if any - ideally very little), and the timeline on which that work will be completed.

For now, if you’ve got concerns about this change, feel free to leave them in answers below and we’ll answer them as best we can. Bear in mind that our plans are not settled yet, so our ability to answer technical or implementation questions may be limited.

Kyle Pollard, who is working on this project, has given more updated information about the transition in an answer post here.

Answer 1

I met with Imgur yesterday and have some more information to share.

The total scope of the data on Imgur is (and these are just rough stats):

• ~2.6 TB of images
• ~48 mil individual images
• ~1.5k requests per second during peak traffic

They 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. We're hoping to redirect requests to a subdomain of sstatic.net or another domain we control. Instead of relying on this redirect, our preference will still be to update any existing images to point to the new domain. We plan to edit the content automatically when we switch over.

We're also working on a migration plan with them. They're working on supplying us with a full list of the IDs in their database so we can ensure that we've moved everything over. When we've received that, my strategy will be to iterate over each of these IDs, see if they're in our own backup, and if not fetch them directly from Imgur. This migration happens later in the project once we've built out a proof of concept, though.

Fun fact: they said their company name is pronounced Image-urr, as in "they're images, and they're yours. Image your!". One dev also said that gif was pronounced "gif" and not "jif", but I'm not sure if that's an official company position or not. 🤠

Answer 2

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.

Answer 3

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

Answer 4

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!

Answer 5

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.

Answer 6

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.

Answer 7

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?

Answer 8

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).

Answer 9

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.

Answer 10

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?

Answer 11

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"

Answer 12

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.

Answer 13

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.

Answer 14

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?

Answer 15

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.

Answer 16

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?

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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?

Answer 21

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):

Answer 22

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

Answer 23

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?

Answer 24

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)