IF the generator for the text strings in question is a fixed technical requirement and can not be changed.
If possible use BOTH a font that makes the characters as distinguishable as possible such as a font intended for software development like JetBrains Mono AND colour code the character classes (alphabetic, numeric, other) NEITHER is a is a perfect solution by itself and even BOTH together is less than ideal, but it should give the user the best chance possible given a generator that produces potentially ambiguous characters. As with any colour based UI you should consider colourblindness.
Even with other solutions that alter the generated string, its still a good idea to use a font optimized for individual character recognition. Especially important, if the digit zero is possible, even if the capital letter O is not, use a font with a dotted or slashed 0 glyph, preferably dotted. It would also be a good idea to use a font with lining rather than old style digits if the string contains digits.
IF the generator can be altered to accommodate usability concerns and compactness of the string is concern
A very simple solution would be to just use hexadecimal. Just about any platform you might be using should have the ability to produce a hex representation of a number easily and many people have seen it before even if they don't recognize what it is so you gain at least some potential familiarity. If you use hex, make it case insensitive.
Even just decimal would be viable although a comparable string would need to be somewhat longer.
A curated character set that eliminates potentially confused pairs and is case sensitive using characters readily typed on most keyboards can be notably shorter but it much less friendly to a human. This set is 50 characters for instance but it requires the user type random capitalization correctly.
34678ABCDEFGHJKLMNPQRTUVWXYabcdehkmnprsuvwxyz@#%&*
A longer but easier type string is probably better for most users.
If using numeric codes, make sure to use a font with a dotted or slashed zero to be safe. For hex or curated characters it might still be worthwhile to highlight the character classes in different colours just to provide a bit of additional context for the random string of characters.
IF the generator can be altered to accommodate usability concerns and readability is more important than compactness
Use a string of randomly selected words. This is conceptually no different from a string of random character except using a dictionary of words in place of an alphabet of characters. Fewer words are needed than characters provided the number of words in the dictionary is larer than the alphabet. The overall length of the string will still be longer than a comparable "character" based string though.
If you see the word "call" that's obviously two lower case 'L's even in a font that makes 'l', 'I', and '1' hard to distinguish. This is a particularly useful approach if the string might need to be dictated to another person.
You can improve the human friendliness by giving the random string a grammatical structure to mimic a sentence. "adjective noun(plural) verb(plural 3rd person simple present) adverb" works well for English. It could be extended with "preposition adjective noun(plural)".
The result is semantically nonsense, but it fits the random information into a form where humans are good at handling it.
Besides length, the downside of this approach is it's more complicated to create, and if you need to handle different languages they each need their own dictionaries and if used, grammar templates. You also need to be aware of homonyms and other easily confused words and words with multiple spellings (their/there, colour/colour, accept/except)
Examples of this idea in slightly different contexts are the Diceware password scheme, the Jitsi Meet conference software which generates nonsense sentences as meeting IDs, or the PGP Word List for dictating key fingerprints over the phone. The EFF also provides alternate word lists for Diceware that could be leveraged for your use case.
Hybrid approach
You could even use multiple approaches together.
Start by generating a random 32bit unsigned integer.
Present it as hexadecimal.
Turn each byte into a word from a list of 256. You could use the PGP Word List or use 4 lists of 256 (Adjectives, Plural Nouns, Verbs, Adverbs) and fit them into the template "adjective noun verb adjective"
That gives a set of words that have the exact same information as the hexadecimal. The validator can then look at what the user types and decode it as either hex or code words to get the number.
You can send both and instruct them to use whichever they prefer, or have a toggle to switch which is displayed to them, or make it an option they set ahead of time depending on the situation. Similar word lists of 256 could be made for other languages that need to be supported and the hex provides a fallback for unsupported languages.
If you want to up it to 64bit you could use the template "adjective noun verb adjective when adjective noun verb adjective"
Abstract skies drop how when urban carbons teach this.