This behavior is fundamental to the way secure HTTP (HTTPS) operates:
The HTTPS "security envelope" specifies a specific closed, protected and encrypted path between the certified server (server certificate), and the session-specific identified client, your browser, which self-certifies for the purpose of completing this loop.
If an https://... URL needed to be displayed as a preview in chat, that would mean that the chat server is identifying itself to the secure server hosting the https site, your browser is not the authorized "consumer" of this secure circuit.
While a server-side script could be written to access secure sites and display them unsecured, acting as a proxy, this would (a) violate the very rationale of a secure connection, and (b) permit the bypassing of server security thus allowing unauthorized viewers to access the secure site that may be restricted to the actual client of the chat site.
This is not to say that this is not done - From way back in the history of web browsers, there have been proxy sites that have done this.
Further, one method that has been used to protect the security envelope and yet provide the content of a secure site within an unsecured (or separately identified / certified) server's content, is the use of iFrames or the like, essentially a browser control embedded within the browser page. If the end browser does not have authority to access the secure site, the iFrame would thus display a blank block or an error message. Not elegant in a chat, of course.