diff --git a/index.bs b/index.bs
index 68f6389f..5735b13b 100644
--- a/index.bs
+++ b/index.bs
@@ -2932,8 +2932,9 @@ Always define a corresponding MIME type and extend existing APIs to support this
 for any new data format.
 
 There are cases when a new capability on the web involves adding a new data format.
-This can be an image, video, audio, or any other type of data that a browser is expected
-to ingest. New formats should have a standardized MIME type, which is strictly validated.
+This can be an image, video, audio, text, or any other type of data that a browser is
+expected to ingest. Use a strictly validated standardized MIME type for new formats.
+New formats containing text should only support UTF-8 encoded text.
 
 While legacy media formats do not always have strict enforcement for MIME types (and
 sometimes rely on peeking at headers, to workaround this), this is mostly for legacy
@@ -2946,8 +2947,8 @@ they are safelisted in both ingress (e.g. decoding from a ReadableStream) and eg
 For example. if you are to add an image format to the web platform, first add a new MIME
 type for the format. After this, you would naturally add a decoder (and presumably an
 encoder) for said image format to support decoding in HTMLImageElements. On top of this,
-you are also expected to add support to egress points such as HTMLCanvasElement.toBlob()
-and HTMLCanvasElement.toDataURL().
+you are also expected to add support to egress points such as `HTMLCanvasElement.toBlob()`
+and `HTMLCanvasElement.toDataURL()`.
 
 For legacy reasons browsers support MIME type sniffing, but we do not recommend extending
 the [pattern matching algorithm](https://mimesniff.spec.whatwg.org/#image-type-pattern-matching-algorithm),