A Forth char is a byte. Forth programs use chars to represent ASCII characters or other data that fits into a byte.
But the world has moved on since ASCII, and now the dominating character set is Unicode, and it is supported by Forth in its UTF-8 encoding. Forth has extended characters (xchars, see Xchars and Unicode) which map to Unicode code points. An xchar for an Unicode code point is represented by 1-4 chars in memory, or one cell on the data stack.
So is an xchar a character (a user-perceived character in Unicode terms)? Unfortunately, the writing systems unified by Unicode are too complex for that idea to work in general; e.g., characters can be composed of base characters (one code point) modified by diacritical marks (0 or more additional code points). So in general a user-perceived character cannot be represented by a single cell. So the way to go is to represent text (including a single user-perceived characer) as string.
Once you embrace the idea of working with strings instead of with characters, you find out that you rarely need to deal with individual code points, and therefore rarely need to use words from the xchar words (see Xchars and Unicode). Also, given that a string consists of bytes aka chars, you can use the words that deal with chars to work on strings containing Unicode characters. In Unicode terms: the strings are processed on the level of code units (bytes for UTF-8), not code points.
You can use the usual integer words on chars and Xchars on the stack.
In UTF-8 each ASCII character is encoded as single byte with the same
value as in ASCII. The same holds true for all other character
encodings supported in Gforth. So you can use the character words
(e.g., c@) to deal with ASCII characters. Only ASCII
characters are represented as single bytes in UTF-8, so this benefit
stops there. In particular, the Unicode code points 128–255 are
represented by two-byte sequences in UTF-8.