Is it safe to use a rich text field with a document library in SharePoint Online?

[Kirk Liemohn]

As a list/library manager, I am able to add a rich text field directly to a list but I am unable to add a rich text field directly to a library.  It seems like I can work around things by creating a rich text field to a site column and then add that to a document library, but then it just behaves like multi-line plain text field.

What I am able to do is create the rich text field and add it to a library via code.  It seems to work just fine with both the modern UI and the classic UI, but I am wondering if I am asking for problems if I do so.

Is there a reason why rich text fields are not easily configured for document libraries?  Are there other places in SharePoint where they are used (maybe some library templates that use them) that would give some comfort that this is not going to break on me?

[#2]

This sounds strange to me, document libraries are in the end lists prepared to store documents so there won't be any difference when adding columns to them

[#3]

It sounded strange to me as well.  We had this requirement for a project and had a problem implementing it.  I assumed it was only an issue with SharePoint Online, but I checked in one of my SharePoint 2010 or 2013 VMs (I forget which) and it had the same issue, so this limitation has been around a while.

As I mentioned in my question, it could be that some site or library templates already have this capability baked in (maybe something with publishing sites), but I haven't explored enough to find anything.

[#4]

What is the end goal of the project? I've used a quick work around of having a list and library in tandem, storing the files in the Lib. but using the "Image" feature of the list to display the thumbnail in the list via the corresponding URL. This also increases the integration possibilities with FLOW and other workflow functionality. 

Not ideal or super scalable, but it works.

[#5]

The goal is to provide metadata on files that we are moving from another system and keep that metadata intact once in SharePoint.  Since the metadata is HTML in the other system, we need to make it available as rich text without losing fidelity.

Your idea of using a separate list could certainly work, but might make it harder to work with the data.  I'll probably have that in my back pocket as a plan B - so thanks for suggesting - and only use it if I hear from someone why the current approach would likely break in the future (as it is working now).

[#6]

Yeah if just retaining the metadata is the goal, your current approach is probably the most scalable and stable. It would be cool to have Rich Text in Doc Libs as a feature though.