Thanks to @yoda for the idea!

When you upload an image using the SE uploading dialog, it gets uploaded in exactly the same size that the file is in. For large images, this can be a problem since they take up a lot of space and screw the alignment. The uploader doesn't allow for resizing (except by manually changing the URL to one ending in s, m, or l.

This script provides an improved upload dialog:

## Usage

I haven't made it hijack the image upload button yet (I may do this later, I don't want to destroy a user's image uploading capability if this has a bug). It has its own button, marked with a "T" in the editor toolbar.

The small/medium/large use Imgur's special s/m/l URLs (if you append s,m, or l to the URL, you get a resized version of the file).

Note that medium and large do not work is the width of the image is less than 640 and 32o px respectively. small will force the image to be a 90×90 square, downscaling/upscaling and cropping it in the process if necessary (source). Use the option described immediately below if you would like to bypass these restrictions.

If you want even more control over the image size, use the height/width textboxes, which generates an <img> tag (allowed in MarkDown). Leaving one of the two textboxes blank will preserve aspect ratio.

Additionally, there is a very useful "link to fullsize" option at the bottom, for creation of true thumbnails.

-
lunboks wrote that l and m have no effect if the image is already less than 640 and 320 pixels wide, respectively. Would it make sense to add an l or m if someone adds a custom value for width? (I'm afraid it will only complicate things; it's just that using the original image with <img width=...> does not lower the bandwidth for those who're not interested in the actual image. But maybe you already thought about that.) –  Arjan Jun 30 '12 at 13:53
And lunboks wrote that the resized images are always JPEG, which seems to be true. So, maybe change the extension too (just hardcode 'l.jpg' rather than 'l.$1')? It works with the original extension too, but it's just not 100.00% right. ;-) (In one test I saw some binary PNG data, not JPEG data, but I cannot reproduce that. Things might be different if there's no need to rescale?) – Arjan Jun 30 '12 at 14:02 @Arjan doing the custom value thing requires me knowing the image size beforehand. Which can be done (in a roundabout way), but it will make the script much slower. Yep, I'd already though about this--along with a few other things requiring the image dimensions--I've planned them for later. I'll make the .jpg change Monday or something. Thanks for the feedback! :) – Manishearth Jun 30 '12 at 14:14 I wonder if you really need to know the image size? If someone enters a width less than 320, then you can use the m thumbnail? But even then: it may still NOT be worth the effort, as you cannot do the same when someone enters a value for the height (unless, indeed, you would know the original dimensions, and hence the aspect ratio, to do some math). Another aside: given the fixed post width of about 600 pixels on the regular Stack Exchange sites, and much less on the mobile theme, I suddenly think we all could always use the l image? Too bad that's making PNGs into JPEGs then. – Arjan Jun 30 '12 at 23:20 @Arjan hmm, you wouldn't, really. Unless there's some issues with imgurs resizer for images with a very skewed aspect ratio for m and l as well (there is one for s, need to test the other two). And yeah, the "large" thing makes sense-- I'm not going to alias the "normal size" option with "large" (removes functionality), but I can add a note to this post. And maybe some tooltips or something. Interesting point, though--I'll try to use l for my images from now on :) – Manishearth Jul 1 '12 at 3:16 Be prepared for a link to I LOVE JPEG!! JPEG! JPEG! when posting screen captures then ;-) – Arjan Jul 1 '12 at 9:59 ## 1 Answer Does not work on Firefox with NoScript addon - even if github.com is explicitly allowed, and even if NoScript is set to "Allow Scripts Globally (dangerous)", one still gets in Error Console (Ctrl+Shift+J) in Firefox: [NoScript] Blocking nosniff Javascript served from https://raw.github.com/Manishearth/Manish-Codes/master/StackExchange/ThumbnailUpload/ThumbnailUpload.js?rand=16 with wrong type info text/plain, inline and included by Thumbnail Uploader Here is the relevant post from NoScript forums: InformAction Forums • View topic - nosniff is blocking a script without telling me I can't think of any reason why NoScript should block scripts without indicating that it is doing so. It just leads to frustration. [...] Not sure it's worth the effort: careless developers like that will soon be forced adapt, since IE9 doesn't give any visual clue either of this (correct) blocking [...] Also, cannot cheat by downloading the script locally (SourceForge.net: MathJax: Greasemonkey script): Unfortunately, GreaseMonkey will not allow you to load a local file (i.e., a file:// URL), for security reasons. (Personally, I think you should be allowed to authorize specific scripts to be loaded that way, but I didn't write GreaseMonkey, so don't get to make those choices.) Well, that's a shame :/ ... EDIT: Many thanks for the quick update from the author (first saw the update on GitHub, then the response here :)); I tried the NoScript version - and indeed, now the toolbar button "T" shows - but the iframe cannot be populated: I tried to mess with the script locally, and I think the breakage got induced already at if(iframeWin.$){ \n var script = iframeWin.document.createElement("script"); ... but cannot tell much more than that...

EDIT2: Disabled NoScript completely, uninstalled the NoScript version, reinstalled the regular version (with Firefox restarts inbetween) - and the behavior is the same as listed above: the toolbar button appears, but the iframe is not populated.

So the NoScript.user.js version indeed solves the NoScript problem - but it seems the empty iframe problem is due to Firefox or Greasemonkey specifics, and not due to NoScript blocking.

-
I added a NoScript version: github.com/Manishearth/Manish-Codes/raw/master/StackExchange/… . It should work. Note that you need to allow jquery as well. Let me know what the result is :) [I strongly suspect that it may not work since the script uses iframes, which themselves load jquery] –  Manishearth Feb 2 '13 at 13:35
Many thanks for the quick update, @Manishearth ! I tried the ThumbnailUploadNoScript.user.js, and allowed ajax.googleapis.com (allowed temporarily "entire page") and the results are in the post update above: toolbar button appears, but as you noted, the iframe unfortunately doesn't populate ... Many thanks again - cheers! –  sdaau Feb 2 '13 at 14:50
Hmm, you're right, some issue with FF/GM. I made it on Chrome, and it used to work on FF. Not sure why it's no longer working, will look into it when I get the time :) –  Manishearth Feb 2 '13 at 15:39