Quick image resizing and markdown image dimensions

I think the encoding difference is pretty obvious, it’s almost 2x as large using hex encoding vs. base64 encoding, for the same 128-bit GUID.

1 Like

Google Photos also switched to base64 (?) encoding some time ago for shared photos… Shorter URLs, but still as secure as the long ones.


I know the technical reasons so I’m not expecting an easy solution, but I do find it sad that in such forward-looking software as Discourse, computerese like this is visible to the user at all.




is neither here nor there, really.

It is 80% file name though. So that is the reality. Count the chars!

The hostname is 41 chars, and the image ID 40 chars in the first example. The full URL from // to .png is 104 chars. I bet you could shorten that URL a lot with a suitable CNAME. Register a WX.YZ host and assign two or three character labels there:


44 versus 11.
(Of course, Czechoslovakia doesn’t register hostnames anymore.)

I already mentioned I can make image:// work :lollipop:



is 134 characters, of which


is a whopping 105 characters. That means 78.3% of the string is the filename :exclamation: Without the filename altogether, the markup is


with the smallest possible URL path it would be 78 characters


which is a reduction of 57% in size!

That assumes, however, that:

  1. we can map to a tiny 2-char domain dm.cd.cs
  2. we can use o instead of original in the path
  3. we can switch to base64 encoding instead of hex encoding for the GUID in the filename

cc @zogstrip

1 Like


works without any changes to storage, and a fairly straight forward change to the md pipeline

No magic domains needed.


Nice, let’s make that so when you are back, then! :+1:





@sam is working on this now so we should be able to get




which I, at least, view as a substantial quality of life improvement for day to day image handling in posts.

(note that we’ll need to use base62, to avoid the / and + chars in URLs though)


Just use URL-safe base64 - uses - for 62 and _ for 63. https://tools.ietf.org/html/rfc4648#section-5 base64 - GoDoc


Cool up to @sam how he wants to handle it, then. Not a huge fan of - and _ both (potentially) being in URLs though.

This is now implemented, I opted for base62 cause it is super friendly on the eyes. I could have allowed $ and * or some other stuff in the URL to shorten it some more and bring it up to base64 but honestly I feel base62 is good enough ™



Very nice!