# Quick image resizing and markdown image dimensions
**URL:** https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812
**Category:** Announcements
**Created:** [July 25, 2017, 9:29pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812 "2017-07-25T21:29:52Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 25, 2017, 9:29pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/1 "2017-07-25T21:29:52Z")
As of today when you paste in images we no longer use `IMG` tags. So for example:
Generates the Markdown
```plaintext
```
I also added an Ninja ⚔ feature that allows you to quickly scale images down
```plaintext
```
So by adding `,20%` you scale the image down to `20%` size, this is particularly handy for people who paste in “retina” screenshots end end up having double sized images. A quick `,50%` will make the image look just right.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [July 26, 2017, 1:25pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/2 "2017-07-26T13:25:08Z")
> [@sam](#):
>
> So by adding ,20% you scale the image down to 20% size, this is particularly handy for people who paste in “retina” screenshots end end up having double sized images.
This is so incredibly useful - I didn’t know I needed it until it existed! A very tiny issue I keep having is that I naturally edit it into
```plaintext
```
which then doesn’t work because of the space… Any chance the whitespace could be ignored? Or is that gonna cause issues elsewhere?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 26, 2017, 1:40pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/3 "2017-07-26T13:40:37Z")
I do not think it will cause any issues, feel free to submit a PR for (and make sure there is a test) I would just add a `\s*` to the regex or something…
---
### Author:  [@Pad\_Pors](https://meta.discourse.org/u/Pad_Pors)
#### Post date: [July 26, 2017, 2:38pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/4 "2017-07-26T14:38:34Z")
nice feature 😃
is there any way to add alt tag to images in this Markdown?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 26, 2017, 2:39pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/5 "2017-07-26T14:39:43Z")
`very good` is the alt tag in `very good|100x100`
🕶
---
### Author:  [@Pad\_Pors](https://meta.discourse.org/u/Pad_Pors)
#### Post date: [July 26, 2017, 2:41pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/6 "2017-07-26T14:41:43Z")
thanks, easy and handy 🤩
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [July 26, 2017, 2:45pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/7 "2017-07-26T14:45:42Z")
> [@sam](#):
>
> So by adding ,20% you scale the image down to 20% size
Another small suggestion, maybe the auto-generated markdown should include 100% to make this ninja feature more discoverable?
```plaintext
```
(This might actually be an alternative, bot not mutually exclusive, help for the @david’s issue too, if the default text would be there without a space)
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 26, 2017, 2:49pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/8 "2017-07-26T14:49:58Z")
I thought about this, I have mixed feelings about it. Maybe… @codinghorror what do you think?
We always wanted to allow people to “resize” using preview, this kind of unlocks that feature, but it is going to be a bit before `markdown.it` has proper source maps to support it.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [July 26, 2017, 2:53pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/9 "2017-07-26T14:53:31Z")
Here’s a PR for the whitespace thing
[https://github.com/discourse/discourse/pull/5000](https://github.com/discourse/discourse/pull/5000)
I agree with @mcwumbly that including the 100% automatically would be good for discovering the feature - happy to add it to the PR if the team agrees.
(Also, I got pull request #5000, yay 🎉)
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 27, 2017, 5:39am UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/10 "2017-07-27T05:39:40Z")
No, I don’t think adding more noise to every image is a good idea. Ideally `srcset` would work transparently to the user. Manually resizing images is very advanced user scenario, I can’t even recall a time I needed to do that here in the last 6-12 months?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 27, 2017, 10:21am UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/11 "2017-07-27T10:21:39Z")
So the old method inserted
`
`
the new method inserts
``
While this is definitely a nice quality of life improvement, our default filenames are pretty bad.
`3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png`
Surely we don’t need _that_ many characters to make each filename unique?
---
### Author:  [@Tom\_Newsom](https://meta.discourse.org/u/Tom_Newsom)
#### Post date: [July 27, 2017, 10:43am UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/12 "2017-07-27T10:43:22Z")
Anything wrong with preserving original filename, appending digits for duplicates?
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [July 27, 2017, 11:10am UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/13 "2017-07-27T11:10:07Z")
I believe those long, random filenames are a security measure since uploaded files are accessible by everyone who knows the filename. Those long names are quite hard to guess…
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 27, 2017, 12:05pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/14 "2017-07-27T12:05:20Z")
Md5 would probably cut it here.
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [July 27, 2017, 12:10pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/15 "2017-07-27T12:10:16Z")
I see that GitHub uses a similar strategy, so is the existing one that Discourse uses worth changing?
For the record, the 4970\_1 was the original filename of the image I dragged/dropped, what is in parenthesizes is the filename GitHub created for storing the image.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 27, 2017, 12:12pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/16 "2017-07-27T12:12:54Z")
Probably not, but we could shorten to image://sha1.png quite easily, which helps
---
### Author:  [@Vitaly](https://meta.discourse.org/u/Vitaly)
#### Post date: [July 28, 2017, 10:30pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/17 "2017-07-28T22:30:06Z")
I’s say, it worth to use term “random bit length” instead of “algorythm”, because any good hash function will be ok. Usually, 128 bits should be ok, but very big hostings (like “yandex photos”) switched to 512 bits. Also, timestamp can be used to reduce random part (see mongodb algorythm for ObjectID).
Another way to save ~25% is use of base58 encoding or similar (base64 is not url-friendly).
Quick estimate: 128 bits + base64 =\> 128/6 =\> 22 characters.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 28, 2017, 11:06pm UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/18 "2017-07-28T23:06:59Z")
That is correct, base64 encoding [of 128 bits GUID](https://blog.codinghorror.com/equipping-our-ascii-armor/) should produce 22 chars:
`7v26IM9P2kmVepd7ZxuXyQ`
You can do ASCII85 encoding to achieve 20 bytes but the characters used are no longer filesystem friendly and that does not seem worth the additonal pain:
`[Rb*hlkkXVW+q4s(YSF0`
Compare with what we currently have @sam …
`e76d2a89947069f0ce624d5989fa20c47a13d383`
`7v26IM9P2kmVepd7ZxuXyQ`
… quite the difference, we could lop off 16 chars there.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 29, 2017, 11:56am UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/19 "2017-07-29T11:56:16Z")
8 posts were merged into an existing topic: [Is using a GUID for an uploaded filename secure?](https://meta.discourse.org/t/is-using-a-guid-for-an-uploaded-filename-secure/67062)
---
### Author:  [@elijah](https://meta.discourse.org/u/elijah)
#### Post date: [July 30, 2017, 6:09am UTC](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812/20 "2017-07-30T06:09:30Z")
So far, only @sam’s `image://sha1.png` sounds good to me. And I don’t feel any strong love for that. Why do you care how clean or ugly a filename a user doesn’t have to type in themselves is?
All the other ideas seem like more complexity for little gain. The whole idea of using a hash is that identical uploads can easily be optimized for disk space. Changing to some other ID doesn’t achieve that. You could store and save the SHA1 in the background and give out the same GUID for it, but there’s that complexity.
(And using MD5 is bad since there’s a non-zero chance someone will want to post deliberate collisions. But as easily forced SHA1 collisions will probably be upon us soon, too, maybe the complexity would be good?)
[Next page](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812.md?page=2)
`
the new method inserts
``
While this is definitely a nice quality of life improvement, our default filenames are pretty bad.
`3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png`
Surely we don’t need _that_ many characters to make each filename unique?
---
Anything wrong with preserving original filename, appending digits for duplicates?
---
I believe those long, random filenames are a security measure since uploaded files are accessible by everyone who knows the filename. Those long names are quite hard to guess…
---
Md5 would probably cut it here.
---
I see that GitHub uses a similar strategy, so is the existing one that Discourse uses worth changing?
For the record, the 4970\_1 was the original filename of the image I dragged/dropped, what is in parenthesizes is the filename GitHub created for storing the image.
---
Probably not, but we could shorten to image://sha1.png quite easily, which helps
---
I’s say, it worth to use term “random bit length” instead of “algorythm”, because any good hash function will be ok. Usually, 128 bits should be ok, but very big hostings (like “yandex photos”) switched to 512 bits. Also, timestamp can be used to reduce random part (see mongodb algorythm for ObjectID).
Another way to save ~25% is use of base58 encoding or similar (base64 is not url-friendly).
Quick estimate: 128 bits + base64 =\> 128/6 =\> 22 characters.
---
That is correct, base64 encoding [of 128 bits GUID](https://blog.codinghorror.com/equipping-our-ascii-armor/) should produce 22 chars:
`7v26IM9P2kmVepd7ZxuXyQ`
You can do ASCII85 encoding to achieve 20 bytes but the characters used are no longer filesystem friendly and that does not seem worth the additonal pain:
`[Rb*hlkkXVW+q4s(YSF0`
Compare with what we currently have @sam …
`e76d2a89947069f0ce624d5989fa20c47a13d383`
`7v26IM9P2kmVepd7ZxuXyQ`
… quite the difference, we could lop off 16 chars there.
---
8 posts were merged into an existing topic: [Is using a GUID for an uploaded filename secure?](https://meta.discourse.org/t/is-using-a-guid-for-an-uploaded-filename-secure/67062)
---
So far, only @sam’s `image://sha1.png` sounds good to me. And I don’t feel any strong love for that. Why do you care how clean or ugly a filename a user doesn’t have to type in themselves is?
All the other ideas seem like more complexity for little gain. The whole idea of using a hash is that identical uploads can easily be optimized for disk space. Changing to some other ID doesn’t achieve that. You could store and save the SHA1 in the background and give out the same GUID for it, but there’s that complexity.
(And using MD5 is bad since there’s a non-zero chance someone will want to post deliberate collisions. But as easily forced SHA1 collisions will probably be upon us soon, too, maybe the complexity would be good?)
[Next page](https://meta.discourse.org/t/quick-image-resizing-and-markdown-image-dimensions/66812.md?page=2)